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

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

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

扫描二维码登录本站

QQ登录

只需一步,快速开始

搜索
查看: 451|回复: 0

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

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

参加活动:0

组织活动:0

发表于 2018-10-19 11:02:45 | 显示全部楼层 |阅读模式 来自- 广东广州
本帖最后由 adminlily 于 2018-10-19 11:12 编辑 2 b& [$ Z: V% ~: y" z$ m, n1 A/ w

2 i/ K% \+ [! D& E) C7 C; p; d
- t: W; M. r  X; n# i# n
这是一个新概念风起云涌的时代。 就让我们从云端抓它几个名词下来,一起玩耍吧!!! 「敏捷软件开发」,「增长黑客」,「持续集成」,「DevOps」,「精益创业」,「持续交付」,「大数据」... ...8 a( k% X' m. Q) k( {. N
* R; N- K" k' L& Q* f* e( \* @

4 Z. k/ ~' Y* b, a$ o
OK,就这四个啦:
. y- n" _; Z/ {, b

, y; r2 j7 @* y9 ~1 [/ l' x. ^1 V+ ?
「敏捷软件开发」,「持续集成」,「DevOps」,「持续交付」,
5 }" n# h; o2 U* ?
0 O2 F6 B; c* a% {3 f

  ^( m: g' A* C4 b: B0 q5 w) D7 s
先让我们在 Wikipedia 上验明正身。

) q+ j( D8 q; N) {

) Y- o% ]6 x- P
敏捷软件开发
2 J3 ~  e$ W( a

+ |2 a3 l  o; m  l
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.

1 ~2 ~- A% P" b: J; l

. ?  Z+ Q+ d0 p8 }
持续集成
5 X/ H; _6 t9 }% P# l2 J4 z

, I, d8 g$ t" Y+ a8 y% M( }2 c$ [
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.
* v5 C4 A; i, {( R. U

" V" u* V  b. T- A: S' v

  u! O* F3 C: y5 H! B1 d
DevOps
1 b  O6 S7 Q3 t' ?1 A

9 |" v6 v7 }+ c( v0 I
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.

' {. _9 p+ E9 b" W
/ S7 Y" Z7 {0 _8 r3 W. T
我的解读

$ U! K9 I1 {! @

# p" K/ M3 ?5 U5 k. q7 B8 u/ z
1. 敏捷软件开发方法

1 f1 o0 s8 t, z9 z' s( O! U

) g+ L! k; [7 ~% ~
从来就没有一种方法,叫做「敏捷软件开发方法」。因为,IT行业中的「敏捷(Agile)」一词,从2001年它的诞生之日起,就是个软件开发方法集合,当时这个集合中的方法,都遵从敏捷宣言和相同的工作原则(十二原则),它的缔造者是十七位软件工程师(请查敏捷,雪鸟会议)。目前,在这面大旗下,又增加了很多种方法,当然也有很多方法走出了人们的视线。
' W8 J1 s4 i/ M8 a4 l6 s
; @# H( z' J. S; ?9 c4 J
在国内比较活跃的几种方法:极限编程XP(2009年以前),Scrum 及其进化品(2006年至今),精益软件开发方法(2009年至今),看板方法(2012年至今)。当然,现在好象也不再特意强调「敏捷宣言」和「十二原则」了,只在培训课堂上还能听到。

! A9 Y6 |/ \) F% ?3 t
- s4 O0 P) y# s7 n5 h8 _  N
2. 持续集成

& N) c. j/ B. n# d& i' x% z: v

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

( y4 w# }. F9 p# m& X: I* K* j

0 H! U: H9 ~" N& R
在2008年的一次敏捷大会上,运维相关人员就「敏捷基础设施(Agile Infrastructure)」展开讨论,并在2009年以后逐步发展成为一场大规模「运动」,它是期望改变开发团队和运维团队之间协作关系的一场运动。强调开发团队与运维团队的沟通与协作,同时将软件的交付与基础设施变更过程都能够自动化。近年基础设施及工具链的发展,也让 DevOps 多了一些发力点。

8 u* t. m6 \# B2 C) e) a
' j3 ?, B" P5 _3 q% S
4. 持续交付

& G: q- K) B: L' m7 f1 ?5 B/ @; c
% l, b; f0 [' b, {
Jez Humble 和 David Farley 在2010年《持续交付》一书中正式提出这个概念,它在书中被定义为:一系列的原则与实践的集合;通过这个集合,团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为,持续交付有三个支柱,它们分别是持续集成、自动化测试和部署流水线(Deployment Pipeline)。

- ^0 h1 }* ~- w5 L

  i1 b# j0 o* o3 }
它们的关系
3 O/ k9 |; C$ ]+ F# c" U3 g

0 |2 @! ^! S$ L: D* i! b7 a
1. 空间与时间维度

! z) t3 N9 y1 k, V) n/ Z! y- X* a

, k/ L* c+ S8 b
根据以上的信息,我认为它们在空间和时间维度的关系是这样的:
1.png
' Y  x7 a' ?8 h, M3 E, l# k4 |4 \7 K
- [5 _. K5 p$ ^) D( p4 J4 F; ~

( f  Y/ l# [& G  f$ l: C! ~; @( I0 N! ]
上面这个图是从实践或环境的角度来看它们之间的关系。那么,如果我们换一个角度呢?
0 p  b1 H/ ]4 o3 {* h: ^  A5 @
' h% q; z( I+ e+ }7 l) Y- K
2. 人或组织维度
  z& {8 T+ ]3 k0 g

/ g+ _) S! p- v+ z; ^* V
我的微信签名是「别提概念,只解决问题!」。所以我更愿意从解决问题的角度看这些概念。一谈到问题,就有一个经典的话浮现在我脑海里「所有的问题,都是人的问题」。所以,这个角度看到的才是本质。那么,它们的关系是什么呢?
1.png

4 O0 z& c/ ]4 I% ]
3 I) ^; T1 T$ Z; y5 }, E
持续集成,有助于打破开发人员和测试人员之间的「墙」。
! ^: Q+ p' N- p. O5 U& ^

# ?. t6 S8 u, P# q$ o
敏捷开发,有助于打破研发团队(开发+测试)与业务(产品)人员之间的「墙」。
5 ?! b" ?! [4 x# f3 J  h

) g/ t& D) P3 J  w
DevOps,有助于打破开发团队与运维团队之间的「墙」。

; X5 D8 ~+ v* c3 e4 a- {

: o7 z" W6 _0 S$ t* J( L8 I' U
为什么从「人」开始

( r' N, r5 W* W

1 V  J( }% m% v
在我多年的持续交付践行及咨询工作中,总结的经验是:如果希望在最短的时间和成本内,取得最大的收获,那么在一开始,与「人」相比,技术实践并不需要太在意,即:最好还是先从「人」的角度看问题。真正去解决问题时,上面说的种种概念并不是那么重要。它们都是你用来解决问题的工具,而且其中的每一个工具(概念)都包含了很多个小工具(原则和实践)。而且,在解决问题时,你也不必整套选择这些工具。
# c5 r3 X4 G6 O: e1 B) z

3 B, L% K9 _0 P  W% V5 H& p
从哪里找问题
; d1 W: w, L2 }8 y3 V/ E) |% R

8 O3 ], S2 H+ _7 d( r% Q; V" ?/ M! M
从参与者的问题陈述中找问题。比如:

8 i* h4 g+ L: w3 ?: M: s# @
& {9 ~$ c! n* g0 m
老板:
' N+ Z( E" L1 h/ |
  • 「项目经常延期」「做东西太慢」
    0 R% {9 H3 T/ ]
8 S0 d' `3 s: V
产品:
2 B3 p' j" ~  q4 Q1 }3 V! v2 u' v0 |

1 o% O* n8 A" p6 L1 T, q& Q' o: @
  • 「老板的想法总变」

    2 d9 @, {9 W/ w, T
. `5 x: }% U9 ^8 k" r
  • 「事情太多,忙成狗」
    , d2 t) v. W2 i# J3 M  ^4 @% q
6 y3 w& o# |; t. Y% }3 u
  • 「开发说这个实现不了」
    ( o& U) \0 O  d( M" c/ W

8 g4 q, I* D/ Y/ }* S/ K
开发:

8 M/ @2 @4 `" b1 S& U0 S% _
  • 「需求总变」
    ) e; o% w7 S; A, I" d% T

1 o' W( s( [5 |$ |! K
  • 「UI 方案给的太晚」
    " d8 Q5 `& ~: B& V$ u( `
/ h- V5 l2 k- s& C4 f- [9 ^+ p+ E

) v" ~' k* u' u
  • 「活儿太多」
    9 O5 l/ A4 B1 z$ a

2 {( I: f9 x: _8 M
测试:

' O+ Q& ?4 B4 F' \; i$ U; R# b+ R6 B1 l
! Q# j% f; [) |3 W- k  J$ @
  • 「需求变了没提前通知」
    ; w  W/ L/ I; A

2 U5 Q  G$ d) {: O! M  e' \
  • 「测试时间总被压缩,还要背锅」
    3 M. ^4 ^4 N, q% ^1 j5 c$ m

8 ~6 v5 ?: L- ~
8 s  N& W6 M1 u8 d
  • 「重复测试太多遍」
    2 o3 u! {2 E* s% l$ f

% A' _7 R/ W& m
运维:
; E- r% V, h; D  Y. q! E; v6 P
3 {" C5 g0 }5 d9 ~! v% I! i
  • 「每天这么多版本上线,活干不完,出事儿第一个背锅。」
    / h$ G: _3 {6 j. ], _

* g4 g) x# n) O; a$ T) _( {' H
每句话的背后都有很多含义。开挖吧~~

; Z3 I6 [6 b. z' W% D6 ]

" f) J; h+ e" U' M; R- i0 _
提问题的人是问题的创造者,也是接盘侠~' j8 L9 ~/ y9 T

1 t" q' q$ K( q* }
# o" R! b+ w; I, Q
从哪里找解决方案

! ?+ |' \" l3 ~$ j3 U, O

3 Y( L3 _, Z$ r" _' @0 _
在《持续交付》一书的第十五章,提到一个“持续交付成熟度评估模型”。在这个模型中,包含如下六个维度:
( M1 M* c$ {' P5 n
$ j, U6 p( R. f  C! p
  • 构建管理和持续集成
    - _* p1 F# p' \# X7 e

6 W* U" T8 U1 w. V2 }% r* M
) w$ H, i" D/ U
  • 环境与部署

    ; @- @/ c" D5 _) P8 }, e
0 A% y; K2 ^2 |( U8 P
  • 发布管理和和符合性
    5 f7 G, b. C1 o4 L0 i
( r( m4 V& n: N! d/ T9 m
  • 测试
    / s6 e$ L- O1 M
3 j4 N2 {4 Y8 X" G% S# g" x; [
  • 数据管理
    0 l  c6 A1 Z, }( N6 n: V6 \, D9 ~
) t$ Y* O  s- A- V" H: S. R
  • 配置管理

    ; Z2 ?! _; m; s

9 N: \* [) A) g5 I8 \/ Y  C1 F
通过实际工作的验证,我发现,这里面缺失了一些东西。所以,增加了一些维度,并重组了一下,如下图所示:

5 ~' J* ~% _# I
1.png

' l' y/ P$ |: d; I4 l; g: h( U
我也没有称其为成熟度模型,而是「持续交付七巧板」。
' e: g% D. e. F8 z- J& R
4 V$ E- e! G8 Y$ M/ W  s
是的,中国的传统玩具「七巧板」,这个儿时的玩具可以拼出各种各样的图形。也就是说,每个团队、企业都有不同的环境上下文(人也是环境的一部分),解决方案也不必一样,关键是你想解决什么(想拼成什么图形)。
, g  e2 y+ D9 D1 U4 j. g% e; w, g

4 \! J+ R0 Q- r. Y) i( B
找正确的问题去解决

" o% j8 n0 Q% c3 s. U

1 M2 `! X2 w: _! R$ ~. O4 n
上面的诸多概念并不是你的问题或目标,而只是你的工具(手段)。千万不要把手段当成你的目标来实现。很多人问:

- v6 P( r" C0 z5 n) N+ Z' ?1 ?$ X: Q
# L7 r/ K9 |0 s% D% C$ k9 U
  • 怎么做持续交付?

    4 r. L$ ^; A* l- ^

- g0 r0 ^5 v# \' b1 x
  • 怎么做持续集成?
    ) H" g# n: o, n: t. k4 f7 x/ X

* ?6 G, @. w, ^/ D4 I$ b% `6 O
  • 怎么做敏捷?

    : _( m1 g( d5 Y" o- @
, o- q1 @, r0 \$ G, G& l
  • 怎么做 DevOps?

    2 y- `' m+ z0 O1 ?3 q3 z: g8 G) @" l

  P, n# m- K  C  B( Y
我猜测你是想问:是否有捷径做XXX。当然有,多种途径里,一定有相对来说的捷径,但不一定是你期望的那种「捷径」
2 ]9 L! o+ I( \2 K- ^

# ?) x* l. _/ n" C$ C  u5 x
  • 我们做的是敏捷吗?
    * o4 K+ S9 g% E- d3 e7 W
5 F( v- d& d  B: b  T
  • 我们这么做持续交付,对吗?

    ( M3 A# J& v6 u- O# X+ w, @0 r

, k# o& ~/ s5 ~/ f, ^) z
我猜测你是想问:(某个人或部门)这么搞,是不是靠谱啊?

9 n1 G2 x* @/ o
0 }; O, u! C4 n$ s
  • 你这不是敏捷?

    , `* a! D0 u5 \8 c5 l# Z  J/ V3 I
5 ?3 _" S% b! H8 R$ a
  • 你这不是 DevOps?

    $ P- N9 Q8 ]! Y5 B9 ?- H: Z( a

' r% m, r8 b2 W4 X6 F
  • 你这不是持续交付?
    6 \% `& `8 ~. p' C+ e
- i/ r0 b; a# C, K5 U
  • 你这不是持续集成?
    6 h* M, j: _& a2 @9 J5 i
    1 }! R) o$ d. j- s" B; `: D6 {
  [# R6 [) P, |$ i
我想说:无所谓,因为我的在微信上的签名是:别提概念,只解决问题。我们还是先讨论清楚问题吧~
. s; x0 ~# K  L4 `5 i, o

! l0 X% k6 L3 X. H& {
再炒一炒冷饭

3 q5 }  n5 Q% k% L. B

& \4 j2 x% L+ g1 Z3 g: {
2011年,我在InfoQ上发表了一篇案例文章《DevOps,不是一个传说!》,其中有两个评论比较有意思:
3 k' p8 O7 O+ e, S2 S

/ s" y3 [+ t( ^, p  M$ b6 h% f
1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化?
' }: S+ u! i7 _* v. _0 [

+ `* }5 b: M1 v" s1 D
正如我们上面第二张图所示,这个项目的前期工作,的确主要是在敏捷开发的范畴,但文中还是提到一小部分Ops方面的东西,可能评论者没有注意到吧。或者没有看到他想找的内容。

& J- D9 n9 m- `% |

2 J8 Q, p  I9 S% V. J
2. 标题党啊
2 I& E2 j1 y" L* @2 U. j9 T
$ v: o7 v; C# R: d# w4 d$ K
好吧,我承认在那个很少有人提及「DevOps」的年代,我就做标题党吧。

' B( q# E% N) q, h* k/ j( W

* e, C/ l% @2 x5 T* E  k9 t; J$ E
这个案例就混合了上面所有的概念,但在项目里,谁还在意概念呢,达成结果最重要。

% {* S3 W3 a1 X3 n0 L

$ ?+ G1 X  U! l
一、了解环境背景

6 X' l- j/ U2 `& |$ u4 U& C

4 d' ~6 |5 g3 r: ?% G' b
当任何人想要对组织进行改变时(无论改变的大小,你叫它改进、转型或者变革都可以),一定先要了解组织的历史,感受组织的文化,因为组织的历史决定了问题的来源,定义了问题的范围。

! O1 j: z9 ^% a' o7 v

; F! k6 q; p8 h  n. C
几年前的百度,工程管理相对固化,敏捷还在“小步快跑,越变越美”的倡导期(从瀑布到迭代,强调项目管理中的迭代概念)。一个从 Google 跳槽加盟百度的技术经理在自己的部门里倡导“主干开发(Single Branch mode)”,但由于原有的基因特别强大,进展艰难。 而这个项目是在最有百度特质的大搜索团队,试验田是一个10人左右的工程架构团队。
& g5 x& @- q" v$ |5 ~) P9 v5 l
; h+ L# B6 N7 J" @+ X  g
团队间接管理者
3 R! A  Z) q& P

! o1 [3 g! k0 d# B
  • 项目交付不太可控:
    8 D) o2 Y& [* A( c0 n3 J$ U
+ u8 k) C. V. O7 [, H+ k) k# G' q
         我们一直在做计划,但计划性非常差。
$ A+ h4 v8 y5 F' e. `$ J! @

! |& x; T7 S4 H! {9 O  K
         经常有各种各样的情况发生,总会让项目改期。
# s4 f( E. N' B& f3 d( ~5 d

9 D  T9 \# E9 ~  p
团队直接管理者

; n6 s7 ^& _1 t" q9 X) Z

6 P# z5 k1 e6 V1 k. k
  • 我非常希望能够快速交付,但我们对这类架构变动类的项目不知道怎么能做到。

    ; j  K8 w; Y, [: z  C  r( E" k5 `7 C
# x; p9 A: }8 h/ @" ?
  • 这个项目中,有一部份需求必须在XXX时间点完成。
    5 g6 k( y- `0 w4 }3 z5 Z
8 F; J  {5 c/ \; c
团队Lead

) H! X: h7 ]: E) F' k( `! }4 j* s' {
( ~: M5 _$ y1 E
  • 估算不准确、临时插入事情多、项目计划很难做(这里省略一千字)。

    1 u% a$ @3 R1 B$ l3 m
7 ~8 {- P/ |3 h. @4 c* ~
  • 我不知道怎么改进,因为我周围的团队也是这样,而且一直这样工作。

    4 z$ T) j+ @- G6 ~/ p" P2 U3 x
# x( o& f5 T1 B& v
开发人员

4 A( l/ ?  g! X4 G6 o5 y$ [* w- y

' y# p' ^! Q7 N1 q7 N
  • 领导说试一下,就试一下吧。

    ) X5 ~& o3 Q; `. u! d

    / J' e5 h4 I( }* }/ I
测试人员
8 k* g' G- T3 ?1 q* V

! u8 Y7 F) C; I
  • 工作经常被打断。

    ! N* r/ A  H( [/ j) y
( R) a& k8 b; R( v2 |  t* x/ W) z

9 X0 u. i+ N: o. F$ ?3 n9 \7 K
  • 提测质量不高,经常浪费精力。

    0 }, h  F% z1 A- O" p9 ~* ~

! v: G* \  x' E4 h8 D
  • 出了Bug,影响太大。

    , `5 |, x4 W) f, `  w0 l9 t' V

# Y# G3 }, e& V2 }7 w  r$ n; X
  • (这里省略一千字)。

    , m  j) P+ x, D' E7 C; M- w: ^; y$ H
' R% H9 s" q2 K& X) t
二、找到正确的问题来解决(目标)
' r8 E5 P. L* U9 q4 b8 Y; y% `
: t' }& `. f7 M) w) h* p/ o3 C
三个月内:
' \  A+ g2 L2 f5 S  \
: e, r: H- u7 ^
(1)该项目交付时间可预期。
: T6 o, f# U8 O
# F( ^, J) {, V" \; e
(2)建立新的软件开发协作方式。
& d3 [/ z- M. I' e# u  ?
1 N: |$ q2 C$ n: p1 _# Y
(3)建立必要的基础设施,以支持后续的持续发布模式。

; w$ S& _; }2 }1 V9 j, S
& C( z5 x- [& `% T# O$ H# `/ ^
三个月后:

+ [' Q3 i/ x' e! f! [$ @# A

& i1 ]" ?5 F% l4 f1 ^) ?
(1)需求的周期时间缩短,可以短周期上线。

+ H- y! T% _  u( \; Y
# @% U) R5 ]- B1 G
(2)生产环境的质量不降低。

6 u2 v: L" F4 ~
( {/ B7 O$ E' g  {
(3)测试人力总投入降低。

& [+ f5 Y  f2 S; w4 K7 s5 D

/ I% H/ s$ Q2 D, J1 Z, b; b2 e* |) J
在少于30人的团队(61个人也可以~哈哈~那62个人呢~~~)
: K1 ~- M0 K# X3 H8 {+ j

/ f" ^# ]( f) a9 p% E$ C& n4 @
1.通常行为的改变,需要一个半月的时间;
6 {" M) d3 b6 r& V& h
% f: P- ^3 \# h
2.带来强烈可感知的收益需要三个月的时间。

* m% D% z: z  l

) n+ y+ T8 K. c& M
三、承诺是必须的

6 i& D2 {5 w% T/ e; z6 V# O, d

, t; m' z4 {5 ~, h* O
上面的问题(目标)找到了,也要一并承诺。

% B$ W2 t5 ^. z$ P+ L1 E+ }
+ B! Y' I) Z5 Z8 ^
要想让团队和你走,你必须站在前面。
8 l* y4 L( L4 n7 u4 o; K

) s) f4 O7 i& A# Y0 P  d' O
四、培训及过程指导

3 l3 A5 O$ i  f; w4 Y( R  y% \
  O' [# Z- T7 I/ _+ E
需要解决团队提出的任何疑问,如果当时不知道如何解决,也要承认。
4 q5 r5 p4 Q3 `# {8 s/ C+ x

3 R) l8 n! a9 m! c
启蒙培训(1小时)

; o" J. U4 F6 c! i: j
( q- u/ F/ W# u# ]$ @) G  k
对于这种能够直接认识团队每个人的小团队,一开始就别花费太长时间讲大道理,以解决具体问题的方式来启蒙。
( n; I/ C( q. ]* [
- y6 ?' w2 C3 f
. s) _# p+ m: N( l
重新定义工作流程
. O+ _* i$ _$ G! z) @

: `5 Q/ f: O$ ?+ ?" U/ K0 g! D7 V
  • 新的项目工作流程
    ( R. l, @* W7 V/ Q  b
8 ?; e* f, z% @3 O& P7 G3 n* t
  • 新的迭代工作流程
    " f# r& w6 D* J: A% c: C, T
7 s5 h' S8 i  c8 h$ S' c; ^. X1 x0 p1 [
  • 新的需求工作流程
    ( @5 ~( S' ]; [1 X
1.png
7 C& K( ^/ c0 ~( i' m

- ~, a  ^1 Y' W: w8 u+ v& S7 q
, l- f2 G- }4 o. w' Q
  • 新的代码工作流程

    2 p: d  v: A4 `& R4 W
1.png
" i( |; K, Z+ j% K; ~) }
+ R' o: T% R' x% e5 Z7 ^5 ?

  y2 U0 M' E; e1 o$ A
解决新流程中的障碍
! A, i# X: ]( o0 K
6 B) I& a5 ?9 V" q
  • 团队沟通和协作的方式。

    8 H+ p8 U1 Q9 N8 ~4 v6 A4 s& W

9 ^7 S# R+ n6 d8 V9 x+ r/ k5 x
  • 编译环境的准备。
    ; e- w9 j& h# y8 b% I

! U6 G' g# C: }! U
  • 编译时间的缩短。
    ' L3 v* P- t$ T# z% ~0 R- U
$ a( i. j1 Z" `. t) I7 m; ], B
  • 自动化测试策略的制定,比如:我们放弃了原教旨主义的单元测试。
    " z' v$ H; I0 o4 x# ?8 n3 |

      G$ `3 o! c3 g" M" s' o) D8 U
1.png

3 E7 M' }5 ~2 X+ A% m' k0 u1 k

" A7 f0 P! @" Q3 z4 W5 z
  • 自动化测试运行的环境的准备。

    & V8 h" }% s2 F1 t

9 v0 O5 ^6 V) D
  • 自动化测试编写时机与自动化的利用。

    7 v0 n1 s, \0 ^
2 h; i* P5 [$ u* i2 U# ~9 o
  • 自动化测试用例代码管理。

    # Y5 b4 D- q! m! m

1 p1 q* L& D5 p% q: m7 ~
我和运维人员的对话(真实的场景再现)
; e: {6 c  N+ {

6 a( N# p; K. u. V/ _. G
我:我们团队想每两周就部署一次服务
0 e$ l: `8 \; Y

8 l% V. V4 P7 V8 r! A0 P5 T
运维:不行
% g/ Y6 C' i: R
5 O6 z8 r8 ^" J
我:为啥?

/ f7 z; H: k7 [: R4 I5 [9 {
2 ^. \4 R  V3 H5 A0 }
运维:线上需要稳定
! j* h: r# k" u8 {5 {
8 G' b& f2 K3 n5 b% f
我:每两周部署一次,就不稳定了吗?
6 S! M1 |2 d9 W

. ]" n+ B' W  r, ?- I6 j1 Z/ s0 u' j
运维:原来的质量太差,每次上线总是出问题
2 u, D; t2 {6 m' B# _/ l# M

% X# d  V$ b0 `& R+ t+ ^7 a; \
我:现在质量很好
. M# z. e4 q1 a2 @/ G
- K0 c: G% u+ x% X; N
运维:怎么可能?
  Y8 s9 h) S7 `" p& J1 y

  {7 t) U' d6 W( c: B3 h
我:我们改变了工作方法,质量优先,你可以参加我们的站会。你有什么要求,我们都可以满足;

: C% g5 R  a+ Y% n

/ I$ f- ^' }5 Y# }, e
运维:那也不行

0 c/ X! O. {" r* p0 d
0 T( \( @, w5 `# b, @% V3 l
我:为啥
+ N) K2 O+ B* M$ ~! n) {

  r1 \8 {0 q. I2 w5 ?* x
运维:我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次,每次前前后后要折腾两天。现在每两周上线一次,我还哪里有时间去干其它业务线的活啊?

# F: K# D5 c1 A5 \! R/ {/ \9 n3 G
6 d5 t. _/ C+ E4 R( O
怎么解决?
5 y9 ^) x) U0 s. g& _, u% L
8 ~( E5 c) f8 g' t+ M* y
" x# M. f7 d' y8 A5 W6 Y- p
改变部署方式,让他的工作生活美好起来吧~~~~~
! i9 D* h; v( T1 W/ l5 I4 Z
1.png

% V% {7 p4 Z0 E
部署流水线的建立,要求一键部署

3 [; J; w9 M# g

5 m" d' c+ V2 A" r0 Q2 ~% o
运维人员负责编写部署脚本,并做版本管理。
, ]' B* ]9 H) u  v
  J/ `: N/ k/ `+ T% L: L& h+ B
3 b/ {0 W, X$ X1 D% O2 q' q" h+ Q
开发人员在开发自测时使用同样的脚本。
8 @2 _$ g, I4 |6 L+ `

( f% |* i, H$ |9 a: G

7 V( E2 D* d* @" [8 ]- B测试人员在测试环境上使用同样的脚本。
. U$ H  [  h, E; H# u5 I
7 x, y0 v6 D$ a0 U
6 S3 f3 ~+ H! h7 B0 N; \
运维人员在生产环境上也使用同样的脚本。

0 t# b* d6 |. t4 |
, P% M+ p$ M' h0 m

. V5 K) v( c- y4 L
  • 原创:乔梁
    5 s' B& d/ ^9 }) z5 j+ J
* d9 T  @2 d8 O$ w+ F0 |7 L, o

$ A- {6 q9 W; P% q, u4 U" N
1.png

本版积分规则

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

Baidu

GMT+8, 2019-6-17 23:33 , Processed in 0.226548 second(s), 29 queries .

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

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