请选择 进入手机版 | 继续访问电脑版

IT运维管理,ITIL,ITSS,ITSM,ISO20000-ITIL先锋论坛

 找回密码
 微信、QQ、手机号一键注册

扫描二维码登录本站

QQ登录

只需一步,快速开始

艾拓先锋
搜索
查看: 338|回复: 0

了解「持续交付」和「DevOps」的前世今生

[复制链接]
来自- 广东广州

参加活动:0

组织活动:0

发表于 2018-10-19 11:02:45 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-10-19 11:12 编辑
! T4 m/ q: b: D. u0 ]6 |/ J: L& g/ b

+ P& _  c3 Q& T- q- v; k$ K
这是一个新概念风起云涌的时代。 就让我们从云端抓它几个名词下来,一起玩耍吧!!! 「敏捷软件开发」,「增长黑客」,「持续集成」,「DevOps」,「精益创业」,「持续交付」,「大数据」... ...
4 a8 ^. v- t% c# {$ Q* [( u

: P7 M% A/ L; O! t

+ ~9 u6 ]/ t6 Q: Z" f8 S) \1 f
OK,就这四个啦:
# }7 k4 ]- ], M! V* h

3 C2 d/ _; P. y4 C/ Y: g
「敏捷软件开发」,「持续集成」,「DevOps」,「持续交付」,3 {' O  t$ |7 ]/ A0 o6 g
5 P, \( E$ e  e+ x# Z

! x5 b' ^" r/ h4 X1 h. i
先让我们在 Wikipedia 上验明正身。
" C) q# `; |! N' f0 E: E

# V% t% K. q4 H) n& S
敏捷软件开发
/ o# R/ g8 d1 E* v

4 w, x5 U+ N) p' j+ W
Agile software development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.

$ S% B( s4 C4 s2 `0 h) Y5 d

% |- T0 ~0 h9 V" D; X6 W3 V: U
持续集成
( H- i8 x: W; U' m; p
* E: T/ Y* l4 `5 A. R5 v' I9 R3 x. }
Continuous delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time.
; p: U& x6 H! i9 F2 P
- |8 L8 O7 T1 V  h. d
2 M8 u* _- ?7 a3 v  M7 d
DevOps

' c9 D/ T# [% n

  U) w1 M5 A' p! i! M
DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and information technology (IT) professionals while automating the process of software delivery and infrastructure changes.
  o$ C" |+ r  L5 X3 H
% l; t) U+ L$ k9 Z
我的解读

: b! m0 r8 U1 B' a2 r' w/ ^

& K/ Z6 ?+ F4 r
1. 敏捷软件开发方法

" b3 v% P7 `  {7 h  }% d% B0 S
0 G) s9 n0 @% s/ \5 b; o
从来就没有一种方法,叫做「敏捷软件开发方法」。因为,IT行业中的「敏捷(Agile)」一词,从2001年它的诞生之日起,就是个软件开发方法集合,当时这个集合中的方法,都遵从敏捷宣言和相同的工作原则(十二原则),它的缔造者是十七位软件工程师(请查敏捷,雪鸟会议)。目前,在这面大旗下,又增加了很多种方法,当然也有很多方法走出了人们的视线。

$ v1 Q- M6 t& Q/ R, a% z. i) B7 Q' a

; D) B4 x$ ^7 ?9 I4 Z# p8 }
在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum 及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调「敏捷宣言」和「十二原则」了,只在培训课堂上还能听到。

8 ]) X/ J4 w; ]5 u# z

$ {- H0 _/ j6 U* t" a8 [) N1 m( ^
2. 持续集成

" t7 m, n8 y# Y
% _$ K5 B: F% f( N5 ^
早在1999年 KentBack 的《解析极限编程》一书中,对「持续集成」这一概念就有提及,它是极限编程 XP 方法中的十二最佳实践之一。在2004年,Martin Fowler 发表的一篇博文上,给「持续集成」下了一个定义,并一直沿用至今。即:「持续集成是一个软件开发实践, 是指团队成员频繁地集成他们的工作成果,通常每天每个人至少集成一次, 这样在团队内每天都会有多次代码集成,每次集成都有通过自动化的构建(包括测试)尽可能快地发现集成问题。」这个概念已被软件研发团队广泛接受,但是其中提到做法,并未能全部落实,太困难了。 这是正常的,来自极限编程方法的实践,都是有挑战的,否则就不叫「极限」二字了。

* z5 w; l; R. V# [$ b! d2 f# v! I
  C% m& m" H+ x* g  [# B1 S
3. DevOps

9 k: r8 G8 O( U9 r( j
1 i: r2 @+ ]  E# G+ s* I- J! }
在2008年的一次敏捷大会上,运维相关人员就「敏捷基础设施(Agile Infrastructure)」展开讨论,并在2009年以后逐步发展成为一场大规模「运动」,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让 DevOps 多了一些发力点。
2 ^$ T' \  C9 |" D/ |; a/ u6 P

9 S9 E, R- P* ~6 v
4. 持续交付
9 Q% k, h# ~4 c4 P

' x+ z; P3 d$ W' h0 Z6 e
Jez Humble 和 David Farley 在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。
* C' L. I7 \$ ]

+ F3 f: O% M0 ^+ A+ |
它们的关系

/ f9 C0 h, q. }, ]  W6 C8 V6 i
+ a: D& b9 {1 y
1. 空间与时间维度
( }. K! D4 M# k3 p3 q( o
+ F" h' X/ p: q( P
根据以上的信息,我认为它们在空间和时间维度的关系是这样的:
1.png
- M. Q# \$ t9 O/ t& k5 m  }

) N" w4 V! T# y+ d
. Y( j6 Q1 @$ `
上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?
1 s* w$ E" s  _
  h9 F+ U1 w. M' V( m. A9 ?
2. 人或组织维度
6 S+ L- q1 a: w6 ]
% W1 K/ P3 P5 _  C" d' _" W
我的微信签名是「别提概念,只解决问题!」。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里「所有的问题,都是人的问题」。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?
1.png

5 {, C1 W$ E9 u$ \
' M+ |: n3 N) {. u7 C+ l* b: u1 @- E
持续集成,有助于打破开发人员和测试人员之间的「墙」。

& o  T+ @9 F' l% P3 K9 z

, X4 u4 Z, s2 j, M$ H: u( Q
敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的「墙」。
4 W: F0 K" u9 C5 Q
+ q2 f: Z8 E5 ?, s1 D: |1 u
DevOps,有助于打破开发团队与运维团队之间的「墙」。

: w2 ]. v2 j0 R6 J3 N; Y0 k# i
. y/ C+ J& D6 N! v% i* ?1 S: z
为什么从「人」开始

4 G7 v% |7 M' T& j5 `5 X* d

( ]3 r8 j( W- l9 I- f* a9 R
在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与「人」相比,技术实践并不需要太在意,即:最好还是先从「人」的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。
0 e. l# I$ O7 y! ^7 N3 \* j$ g) N
1 @9 i; Y* [& w( x
从哪里找问题

3 H8 y7 T- ?- X1 o( f9 Y5 Q
; f3 ^. x' q, O) w
从参与者的问题陈述中找问题。比如:

. o! h4 U! I3 p7 u

4 _) n0 x* Z# @2 E& K
老板:

  R* Y$ [" m) @' B, \
  • 「项目经常延期」「做东西太慢」
    * i# Q& P# J* [4 E* s- P
; O  y6 R0 s0 m
产品:

! F2 C8 x& V& F+ _# q

4 x6 @8 S: i9 B
  • 「老板的想法总变」
    % F: ^3 |( R4 O( e9 ^

' j7 o  C. m$ ]; P' ^% l# r9 }
  • 「事情太多,忙成狗」

      _2 h$ y( m" y4 n1 @/ \7 o) R
9 x# }- `/ {* D+ J* d
  • 「开发说这个实现不了」

    ' E7 h; _0 x% e9 J7 N* G: q$ d

  W# b8 j! W3 Z' K8 f
开发:
7 g1 v. Q1 n7 w1 {1 l! x
  • 「需求总变」

    8 K4 q& J* ^! s3 k, C! _" H

& H+ N) o+ ~1 z  h! @5 P. i
  • 「UI 方案给的太晚」

    ' ^% m& s$ c& |2 S5 i. r
% H' X  w6 V9 [
" ?/ n% w' J1 e6 y
  • 「活儿太多」

    ) t+ X9 R- x1 A9 g& Q: ~- J! S

' M( A+ ?5 ?5 |" R/ c
测试:
# W& e: L5 k4 C
! O& a# k4 O( [1 P
  • 「需求变了没提前通知」

    - u4 z  W8 V( y: e2 y# a; a1 C' L

) g1 v: v9 x( F; m* Z0 }
  • 「测试时间总被压缩,还要背锅」
    : f: Y; Q+ X, n+ h5 t2 b$ q

/ \1 W  l2 p; e3 x+ i, }% H. o

' a8 ?; q. q% [' D" ]
  • 「重复测试太多遍」
    + a% d+ s, \/ ^$ t3 L

, s4 \- D) Z  n& n# [, B' D
运维:
6 Q& E2 t3 z* o3 O1 R8 A& a) _
7 l$ T) F9 B# ~  Z
  • 「每天这么多版本上线,活干不完,出事儿第一个背锅。」
    . A1 s% \- c4 j9 Z) G" F

; w$ c8 X1 h6 h9 F" I4 }
每句话的背后都有很多含义。开挖吧~~
# d, n5 j) _0 }" q+ v

7 y4 [1 H* w$ }$ {* a3 b
提问题的人是问题的创造者,也是接盘侠~
( l) I9 i$ q$ N; k
1 _5 T2 m8 p4 ~2 I( w% x

2 ~: _4 o( C  n* ^2 N/ M$ L; K
从哪里找解决方案
1 |! a: g$ O4 B# V' w- _4 D1 g* G$ i. \! i
1 ]2 O- e4 O# X7 R0 I/ w1 v2 x7 {7 Z2 f
在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:
/ }4 E* J* u+ G5 R

/ P2 I- {7 x  L- h, A2 q
  • 构建管理和持续集成
    9 z& f$ U% O0 x- X% _+ h

5 p7 V2 I$ x3 L

( m" s5 v1 d- n8 s- N+ @% r
  • 环境与部署
    . @4 a+ L  ], s* N8 A9 c( i8 {
9 _1 H) U8 ~' t" v3 r$ k
  • 发布管理和和符合性
    : d1 u& D& Q! H. }

" l0 \. h9 N' t; s5 x
  • 测试
    " Q' I4 L6 e' ?6 l, O
: [* [1 u: [0 ~6 D0 }  R. x' X. A% S
  • 数据管理
    . `( r, m( U/ a3 \; m
6 A4 {" s& P/ S* l5 r
  • 配置管理
    . Q% I* K/ C# ]( u" a% s& z

: J1 G; E9 A; B" b0 v7 r2 \
通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:

" Z" w) g) z. {. w# p+ v
1.png
, L. {. w" d, T% p9 K+ l. J
我也没有称其为成熟度模型,而是「持续交付七巧板」。
+ w' e; n/ q3 U5 l+ _# I" l

2 ?$ ]  ?; |: @; ~- z% y5 m
是的,中国的传统玩具「七巧板」,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。

; }  u1 b+ p7 v# V8 I
2 F8 w' g, X9 ^. ~/ r
找正确的问题去解决

( p: ?5 l! I8 E8 ~, w
! F/ l: S1 F7 O
上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:

) o; u2 v* P8 t( A$ ^. h' _

2 d$ n  a* H+ D
  • 怎么做持续交付?
    5 O3 R4 R/ k+ G3 E3 W. P9 o9 c5 v) z
! ?& J" k1 M5 l  \. {
  • 怎么做持续集成?
    5 ?9 a  b1 i4 T  n2 G3 _4 I# m8 s8 {
1 D2 A5 A( y1 e! }5 X- b
  • 怎么做敏捷?

    3 c0 M, z+ w* Q$ k/ `

8 b# F, y4 Q0 v6 h7 ^  M
  • 怎么做 DevOps?

    ! ^7 e/ @: i" A  z* v
( d) C: V# F7 w& L! M
我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种「捷径」

; e# c* \  ^2 k6 @$ U

$ q( ]9 n8 i+ c, a& _7 T9 ~8 g
  • 我们做的是敏捷吗?
    5 ~7 @, U: t- g  J
* b3 Q( M  S) t6 o
  • 我们这么做持续交付,对吗?

    ( _3 g7 ?" U3 Q6 ]
0 ]8 O, `6 q. K) `  W' Q
我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?

. r; k5 I$ I- U' G8 M; M
9 D# S* Y- b" U$ ?+ B
  • 你这不是敏捷?

    ( O$ k2 q0 ]5 G/ v! T
5 N& T" e  ^" S+ N' v
  • 你这不是 DevOps?

    2 E! n  S6 W4 ^

3 F+ h. a' d4 _( Q1 T3 U
  • 你这不是持续交付?

    $ m3 ?2 e( M7 q# C, V: f& z2 Z! B
( p& n/ ~; q7 m7 r5 e
  • 你这不是持续集成?
    ; F# {! S, Z8 r0 `# d% N  i
    . Q/ J9 D/ q$ ~3 B6 V" P
1 b9 z0 b) E5 N7 O! ^2 H
我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~

% C  l- W- Y5 F( T3 h4 e2 D
3 V) u0 k2 F, z% w7 e1 N) ~
再炒一炒冷饭

1 J& J( ~* h) U9 d9 _
1 ^2 \# H  b; D( t
2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:
2 s& ]3 @5 K3 M3 l1 Z+ ~
% R% `- _- q  [: q4 I! Q
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?
8 a' j) q3 s" }5 m9 z$ R
; `3 F  v/ q+ N7 `- |
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。
6 p2 P. |# i5 l2 {! D) Z
# r  R% Y. r3 u  _+ A# n7 J
2. 标题党啊

4 I$ l/ Y- M5 N
5 A+ K* `& l, v" ?
好吧,我承认在那个很少有人提及「DevOps」的年代,我就做标题党吧。
! A2 X3 X. O9 X
5 _& ~! @! B- j0 v8 C2 k7 L
这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。
$ z  w& X" }1 R3 P1 v0 ^
, c, ]6 t6 G# d
一、了解环境背景

/ t$ o/ P+ E7 h4 I3 J/ l. P
& y' p, S6 ]7 H# S+ ^" @
当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。

$ R9 h/ U3 _! Y" W  P" y

% [2 X) E6 o1 p- v. S. M" P  S- A
几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念)。一个从 Google 跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难。 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队。
3 M* q! j7 }6 |0 O- t

2 C+ W5 `& L6 w( J4 B
团队间接管理者

: u3 I3 T' r5 {1 Q) C

+ ?# k& O! B; y2 z) ?! m+ F
  • 项目交付不太可控:
    3 u, C7 q3 W1 |& A

3 \% g/ `  ~; t# G* f4 f0 f7 b
         我们一直在做计划,但计划性非常差。

/ o( O$ H1 Z% k$ o6 L& n

2 B3 c1 g0 R- y! }3 `. C
         经常有各种各样的情况发生,总会让项目改期。
, `1 z0 I* O/ z- K6 C/ Y

9 U2 W7 J/ Q, P- k7 f  Z
团队直接管理者
" E  C3 l; B  u

8 K0 T: \$ z! V4 \! C) h9 Z4 ?2 W
  • 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。

    . N: b- f# e! Y: G8 |5 Z# Z
$ r4 X: ?% P( P" Y% e
  • 这个项目中,有一部份需求必须在XXX时间点完成。
    : M+ ~6 U( g0 D- B

9 `# c. f& c; Y2 P% g2 Q* y
团队Lead
0 ]1 N( I% g$ N
1 a1 M! Y7 m6 C* x, V1 t
  • 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。

    : K8 o/ A! J% b, m) A
( a6 V0 q+ E+ [3 h
  • 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。
    & s7 d1 L2 l3 H: i7 a! J/ A
4 B- W0 U4 C1 H: a; p. `
开发人员

; q, c# V) u& U

0 d7 O7 H( E' ^( w  U% K
  • 领导说试一下,就试一下吧。
    + _+ a# d; W1 s

    7 X9 D( x2 p( |! u) n$ G, K  s
测试人员

' x: L- G* [6 o$ ~

/ F( v5 @- H2 G& p7 X0 G
  • 工作经常被打断。

    0 x# [& N1 Y/ a9 a
: O0 @' h$ t  d8 i
3 S) ^3 X+ B7 O. ^% n1 [- `
  • 提测质量不高,经常浪费精力。
    . B; X3 R/ W- J8 F$ f

( X  J) N: S  e4 k& X
  • 出了Bug,影响太大。
    ( }- [; L1 H" q6 W) r5 N! K! z
+ \0 M% ^* Z6 U8 |% h+ Y
  • (这里省略一千字)。
    6 R% ?* j/ y1 t0 ~6 m2 D# r+ u
. s# N  `$ Y2 e- H: C" J
二、找到正确的问题来解决(目标)
% s9 _# v; E" B

/ G% D7 C. G! a4 n
三个月内:
5 o+ y+ I3 D& s* y# T0 e: D
$ O$ y# a- w2 u6 ?  m
(1)该项目交付时间可预期。
; ]. ?  q  s# [- b9 z

- n! s' L+ ^* r' H4 L: d: j
(2)建立新的软件开发协作方式。
* R) ^( H, F- R+ w# Q
1 L3 s: Q* B' N- M5 t
(3)建立必要的基础设施,以支持后续的持续发布模式。

! k# ]' W) X# \. Y, i; l

/ u/ q- c" [6 \* d* f, _2 F
三个月后:

! v7 ^9 V$ @5 w- e  U* r: L) ?: Y
" A, B* J( c+ E
(1)需求的周期时间缩短,可以短周期上线。
# i8 M0 S- H  x4 q* e' v1 u

9 i  ]7 r/ x5 I4 f
(2)生产环境的质量不降低。

; U6 Q! K& u* Q; J8 C9 t

1 i4 `( O+ q% I* t/ Z2 T3 E* j
(3)测试人力总投入降低。
0 d3 B9 c# l* m! F7 S2 I1 V

" E* c" A( u/ [7 k! X1 Q
在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)
0 K* A3 Z' \) q4 b& ^: S& d2 E% L8 n
: p4 d6 G6 W1 ~. m1 d
1.通常行为的改变,需要一个半月的时间;
0 f" E  ?) u: g+ X
( S2 {3 J7 m* f0 i/ h+ M
2.带来强烈可感知的收益需要三个月的时间。
* t+ v9 q, h( X- E* j5 O; a; G
( v" q7 B7 d  L/ V" f
三、承诺是必须的
  I8 K1 ~% G$ E: t4 Z
2 U! R/ g! y: a) J
上面的问题(目标)找到了,也要一并承诺。
" H7 Z9 ?' L& \  ]( x+ G
4 N7 J# W8 U2 @  v) b
要想让团队和你走,你必须站在前面。

7 _# x# ?! R3 M% J5 }; o( Z! w
) F# M& \) \8 e8 b2 Y; \
四、培训及过程指导
! X9 N% ~/ f- z- f- a. J
+ F" W( p! G- u+ Q! l0 Y' T
需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。

5 _# [7 K! U( H8 Q9 F4 o

' z0 r' p# W$ N8 F  Y
启蒙培训(1小时)
$ I. X: V8 w# J2 D

0 _" S* L; x) _1 j/ t5 O& i
对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。
) ?+ x) \7 h) A8 G$ G! j" W

0 v: f2 }# w/ A1 C3 ^7 L

+ T. \3 O+ E$ T( g& p$ P) V
重新定义工作流程

& F9 {) K; }9 f* p% @5 {( r! Z1 I0 N% e0 A0 |# X
  • 新的项目工作流程

    9 p% }& b; Q* o' v/ U6 I4 p
; N% X. E0 _6 A  w" N# `
  • 新的迭代工作流程

    2 T! t3 z5 H" X

' b0 t2 M/ ]# v) ]/ E
  • 新的需求工作流程
    ' W2 G( |- l* g9 N
1.png
, u) h. J8 i# s

) z! {! i4 a# m. J  y1 d. c* x
9 F9 ^& c# {: j7 k# q4 c
  • 新的代码工作流程
    8 v+ \# N9 b( A( t' U; b
1.png
) i% H2 O  S& Y* }  e9 t) w

0 T( w. n' v4 f) Z5 N
3 J5 W" V5 x" y: R
解决新流程中的障碍

0 z; z- v& u5 d

; P$ b6 r& g' l' Q
  • 团队沟通和协作的方式。

    2 Y, S. w8 F) G
6 L: \4 L- _0 ~) }. d
  • 编译环境的准备。
    7 W% C& ~, k! L/ D7 Z
6 P( [: v5 W8 h' k$ r9 v) B6 C
  • 编译时间的缩短。

    # M; N4 B0 r. c# P+ V! G
/ M$ _# ]' D0 Y; u# C
  • 自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。

    0 i4 c, p' c% v! f! o& |% [

    % R* t) l' A$ |9 s& U+ `/ `; Z
1.png

5 E. @2 X$ Z$ i/ ]
8 @* ~( i" Z: H( s: ?9 F' h" r0 y
  • 自动化测试运行的环境的准备。
    ( G3 |" e+ f1 D# r1 Y$ Q8 y( d

0 j3 j- O6 {7 A7 ^5 j% w
  • 自动化测试编写时机与自动化的利用。

    # @' c6 C. W& K! O! V8 W% f
( x5 H; [1 K. p2 D" ~2 B
  • 自动化测试用例代码管理。
      T8 x* r1 t$ S& Z" P* a
  z, G$ \4 z% m/ R8 f* p
我和运维人员的对话(真实的场景再现)
  B3 ^5 v  G# A  R
& |/ ~5 C7 O$ Q) S8 b, J" C4 |# i8 d
我:我们团队想每两周就部署一次服务
- w' ^- ?& N8 I: J" k
" a  X' k4 d) ]( [/ n  c, x
运维:不行
2 ?$ D' ^  f" X0 H" L( T# Y

. ^% y' z1 X& A' ^' t9 Y
我:为啥?

7 \2 M" [8 _$ _+ {, m6 @

6 J7 r! O$ a( n
运维:线上需要稳定

; _' X- ?+ y; I$ `) ]
( q, ~0 q/ X6 G; m. l% a
我:每两周部署一次,就不稳定了吗?
9 A6 v+ F' |3 m! i4 A' U; M  j  ^

0 m% f' P3 M7 Z/ S
运维:原来的质量太差,每次上线总是出问题
3 [; E: u8 w. _8 E( F) X

9 E& o: P" f: c! W
我:现在质量很好

. a$ x) O- t, q1 i  ^. F5 E% D( [2 N

( ~4 Q0 E/ e  P" `6 C
运维:怎么可能?

; U; x. o* ]' x. [' h1 B/ j

: o. S5 h3 c  h
我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足;
" O: p" o# L/ Q( x2 R( S" T" S

$ I' r4 G6 Q  \
运维:那也不行

5 a( {. F* c! P
1 Y/ W  j, [9 `& s! ?/ b
我:为啥
& l# G- e, A7 `4 I+ U
9 |: ?5 @: |) F
运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?
1 X. q& E0 N; B2 v

2 I, F% R/ e+ P& @
怎么解决?% O: W0 Z8 I* ]4 U' u

3 Z4 h# {) A( n0 k+ y* \7 v

2 v8 I- Z) ]/ V" I: T- a; ]
改变部署方式,让他的工作生活美好起来吧~~~~~

( G- i$ S+ c& `- y) V' O: l
1.png

1 L: Z8 x! e' W1 I! o
部署流水线的建立,要求一键部署
4 J" G. Q9 L7 A7 n7 l& k) D& V
% V: {0 `; n8 I. k% N6 U! ]1 e# U' z
运维人员负责编写部署脚本,并做版本管理。
' V! X6 P& D; ]8 d
6 A& ~" N! g: _% H  F0 O; _

0 R  s. C% l7 H' H" x5 F- W开发人员在开发自测时使用同样的脚本。
3 r& @! K" [, z( _+ @* i

. T) V, O4 _( `" F% M3 k& O, L2 g

1 n1 W# M! M+ i* R/ X6 d测试人员在测试环境上使用同样的脚本。
7 g/ Y0 U' F9 a2 A. r7 z+ S
$ W. }1 B/ `8 k3 m

- J$ A' C) L8 o2 }运维人员在生产环境上也使用同样的脚本。

: f* A: C5 k/ k+ ]- m7 u3 a9 |! Q% H6 ~' ~( @) a

/ l  I( I" m1 S- D5 {% Q' f
  • 原创:乔梁% a2 w. K3 u0 V0 ]& h
/ Y- Y$ k" w' O0 H/ U

! P0 c% U9 k8 Q2 \0 W7 D/ y/ ~
1.png

本版积分规则

选择云运维时代的王牌讲师-长河老师,助你轻松入门ITIL Foundation培训课程

QQ|小黑屋|手机版|Archiver|艾拓先锋网 ( 粤ICP备11099876号-1|网站地图

Baidu

GMT+8, 2019-4-25 00:54 , Processed in 0.218667 second(s), 31 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表