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

我行我素

* O' N/ ^( M0 O2 o; y

这是一个新概念风起云涌的时代。 就让我们从云端抓它几个名词下来，一起玩耍吧！！！ 「敏捷软件开发」，「增长黑客」，「持续集成」，「ITILxf.com" target="_blank" class="relatedlink">DevOps」，「精益创业」，「持续交付」，「大数据」... ...
1 {; i/ q$ U6 n  P, n

OK，就这四个啦：

「敏捷软件开发」，「持续集成」，「DevOps」，「持续交付」，
9 F$ J3 B8 z: I' Z/ C) A, R

( g% b" Y% A1 L* ~( a6 J

/ J* Y5 o2 u; }% w5 s& \

先让我们在 Wikipedia 上验明正身。

# L8 O6 n% I5 j  ^* h2 p3 R

9 {: s( v9 b2 F: k: `9 `

敏捷软件开发

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.

/ ]( i# }  o4 H

持续集成

  U# o* {4 ]* H0 l4 ^" j9 |' D3 q

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.
4 F" n6 c0 S$ s# W; A* b$ w, H

DevOps

$ g) g' l% k; H* 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.

. U  z# K6 ?2 }& n" t

我的解读

1. 敏捷软件开发方法

1 U: @8 h/ O1 ~: v6 ]$ I( D1 y

- _( Z: a# C% Z: _. s

从来就没有一种方法，叫做「敏捷软件开发方法」。因为，IT行业中的「敏捷（Agile）」一词，从2001年它的诞生之日起，就是个软件开发方法集合，当时这个集合中的方法，都遵从敏捷宣言和相同的工作原则（十二原则），它的缔造者是十七位软件工程师（请查敏捷，雪鸟会议）。目前，在这面大旗下，又增加了很多种方法，当然也有很多方法走出了人们的视线。

+ s/ p( P6 @! c6 N0 k) Y

在国内比较活跃的几种方法：极限编程XP（2009年以前），Scrum 及其进化品（2006年至今），精益软件开发方法（2009年至今），看板方法（2012年至今）。当然，现在好象也不再特意强调「敏捷宣言」和「十二原则」了，只在培训课堂上还能听到。

# \9 p  J" x. |2 v

0 B3 d/ A% x: F0 d

2. 持续集成

# M$ A% W0 c; ^% E4 M. P. z

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

3. DevOps

5 V6 u0 U  B5 L$ ^$ e7 S+ ^

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

: k; `- k8 s- n: [1 E% }  d

4. 持续交付

5 u0 E: N! H7 k1 x9 _7 E0 y% |

Jez Humble 和 David Farley 在2010年《持续交付》一书中正式提出这个概念，它在书中被定义为：一系列的原则与实践的集合；通过这个集合，团队能够在低成本、短时间及低风险的状态下以增量方式将软件变更交到用户手上。Jez认为，持续交付有三个支柱，它们分别是持续集成、自动化测试和部署流水线（Deployment Pipeline）。

6 x" U. ~2 y0 b" q. R# \- C8 H

它们的关系

- b" G5 v# ^+ t

1. 空间与时间维度

根据以上的信息，我认为它们在空间和时间维度的关系是这样的：

6 }# N5 l+ Q+ R

( ~2 B/ o+ m, v

上面这个图是从实践或环境的角度来看它们之间的关系。那么，如果我们换一个角度呢？

1 H  P7 T4 z  b. Q0 T

' S* `- T* Q% ^: l0 u2 @

2. 人或组织维度

$ k+ [+ a8 ^- F9 o/ u. l& |

我的微信签名是「别提概念，只解决问题！」。所以我更愿意从解决问题的角度看这些概念。一谈到问题，就有一个经典的话浮现在我脑海里「所有的问题，都是人的问题」。所以，这个角度看到的才是本质。那么，它们的关系是什么呢？

- w: n3 s$ P3 r/ t9 i- o  M, r9 E' s

持续集成，有助于打破开发人员和测试人员之间的「墙」。

& X+ L  L- `& [! V- l' X

" I- v* `: ~! ^3 _

敏捷开发，有助于打破研发团队（开发+测试）与业务（产品）人员之间的「墙」。

/ C8 @9 o3 I& K- d) b. W7 K

8 o, q$ z: s# v" n8 D1 X

DevOps，有助于打破开发团队与运维团队之间的「墙」。

6 J0 C/ E! y5 i' K) r1 q

; t7 {5 Y. n/ j$ N, S8 Y* ~( K

为什么从「人」开始

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

$ {4 T, Z: f2 R( E: B. p" j

从哪里找问题

; k/ ?6 b' p3 J0 l" I

从参与者的问题陈述中找问题。比如：

) l* n! C& F( Y' o, T) x

8 w8 L( d" {1 J- H7 v$ M

老板：

, |; U& n. D$ b7 |

• 「项目经常延期」「做东西太慢」
  
  

产品：

' t% G8 g$ l, m* H! U) X

• 「老板的想法总变」
  
  $ w7 N+ u5 f+ d- K5 D3 ?

• 「事情太多，忙成狗」
  
  

• 「开发说这个实现不了」
  
  3 [; h+ _! R! M5 g* I

4 M/ R6 q8 Y  s7 b

开发：

0 l# T4 y; S. E

• 「需求总变」
  
  

• 「UI 方案给的太晚」
  
  

• 「活儿太多」
  
  $ ^# }# m& r# o; B/ ^8 `+ K, F) c

测试：

• 「需求变了没提前通知」
  
  

8 D2 _- ?3 C5 p! Y$ r' C

• 「测试时间总被压缩，还要背锅」
  
  1 o4 Z, v9 m+ e) Z0 B

6 d4 u6 L) U) }0 ?- L

• 「重复测试太多遍」
  
  

运维：

: j+ b! [2 S$ v5 h

$ G: _  q9 X: b0 H# j0 N7 i

• 「每天这么多版本上线，活干不完，出事儿第一个背锅。」
  
  

. l( S7 k- Y8 D2 j' Z

每句话的背后都有很多含义。开挖吧～～

5 b- D) J( W2 G8 U2 ^2 ]& @: e

提问题的人是问题的创造者，也是接盘侠～
7 G% E+ Y. O4 d4 p9 Q5 U% ]

' M' V* C8 e& v1 d: B; I( [

从哪里找解决方案

在《持续交付》一书的第十五章，提到一个“持续交付成熟度评估模型”。在这个模型中，包含如下六个维度：

, l6 o( `) V  d! u# q# l  d

• 构建管理和持续集成
  
  

- q& V0 d, `* N% D3 q, @- N

• 环境与部署
  
  " y+ A. C# U- f! W5 z7 U

& B) j  H% U0 H' n# p

• 发布管理和和符合性
  
  $ X4 q/ R+ z& Y6 B

• 测试
  
  & N+ L- L) \  r7 H( l/ ^8 i

• 数据管理
  
  

, c4 V# x0 d4 ^

• 配置管理
  
  

通过实际工作的验证，我发现，这里面缺失了一些东西。所以，增加了一些维度，并重组了一下，如下图所示：

/ v" [( k6 Q9 @/ j/ ]' M1 M

我也没有称其为成熟度模型，而是「持续交付七巧板」。

是的，中国的传统玩具「七巧板」，这个儿时的玩具可以拼出各种各样的图形。也就是说，每个团队、企业都有不同的环境上下文（人也是环境的一部分），解决方案也不必一样，关键是你想解决什么（想拼成什么图形）。

找正确的问题去解决

; H" n# ?+ N# h% I& x

上面的诸多概念并不是你的问题或目标，而只是你的工具（手段）。千万不要把手段当成你的目标来实现。很多人问：

6 X+ z4 Y4 @& E) ~

• 怎么做持续交付？
  
  % o  N) u9 `) p+ r

- ]+ g3 B3 s8 }

• 怎么做持续集成？
  
  

; @- g+ J6 D: \9 X9 n- u" o

• 怎么做敏捷？
  
  

8 [& b! H8 P8 M5 B: T. @% y9 y: z

• 怎么做 DevOps？
  
  

0 q5 y! q9 [/ X# R0 C! i

我猜测你是想问：是否有捷径做XXX。当然有，多种途径里，一定有相对来说的捷径，但不一定是你期望的那种「捷径」

4 V$ E$ t1 }8 J: O7 k: N# c

• 我们做的是敏捷吗？
  
  

• 我们这么做持续交付，对吗？
  
  

我猜测你是想问：（某个人或部门）这么搞，是不是靠谱啊？

2 ]) S- y" Z' L( Q7 Q4 f4 v

• 你这不是敏捷？
  
  

• 你这不是 DevOps？
  
  . {* M+ P, A! B7 D9 f% l

! Z& o. x! u  i9 D, F( J: ?  t

• 你这不是持续交付？
  
  - ^: \& k% u. D) P$ g& u

& _- r# N5 P1 ^) N

• 你这不是持续集成？
  
  
  * C$ C2 {9 ^# G. o# R/ G' E

/ B2 ]; d) i1 w% `5 d: y1 p

我想说：无所谓，因为我的在微信上的签名是：别提概念，只解决问题。我们还是先讨论清楚问题吧～

* O! S9 y4 Y) X' Y4 k; l+ @( O8 W2 Y

再炒一炒冷饭

8 ]- D. r1 J0 ]- R

2011年，我在InfoQ上发表了一篇案例文章《DevOps，不是一个传说！》，其中有两个评论比较有意思：

; k$ x9 f# X; X2 W- @: I" x% `

1. 怎么感觉就是一个从瀑布模型到Scrum/CI的变化？

* e3 l2 c- p2 Y  [. P1 m: r9 J+ Y

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

; z' ]8 J- z& K7 L

. ~  E( }; _9 G4 W

2. 标题党啊

! j* u5 G) Z9 f; I9 r

( s" e8 H* E% {" v- L

好吧，我承认在那个很少有人提及「DevOps」的年代，我就做标题党吧。

1 B: S7 R! F2 A5 ?

这个案例就混合了上面所有的概念，但在项目里，谁还在意概念呢，达成结果最重要。

9 s# w5 b& n$ s& f  t: i

一、了解环境背景

当任何人想要对组织进行改变时（无论改变的大小，你叫它改进、转型或者变革都可以），一定先要了解组织的历史，感受组织的文化，因为组织的历史决定了问题的来源，定义了问题的范围。

" i( V& i" p& g

: T) v: u6 m  v/ p8 u6 Q

几年前的百度，工程管理相对固化，敏捷还在“小步快跑，越变越美”的倡导期（从瀑布到迭代，强调项目管理中的迭代概念）。一个从 Google 跳槽加盟百度的技术经理在自己的部门里倡导“主干开发（Single Branch mode）”，但由于原有的基因特别强大，进展艰难。 而这个项目是在最有百度特质的大搜索团队，试验田是一个10人左右的工程架构团队。

; ~: r, b2 V9 S. a; B/ \4 S

团队间接管理者

• 项目交付不太可控：
  
  " |( b' T8 @* }% \! W7 u

; B' w3 T7 Z  \9 V, A

         我们一直在做计划，但计划性非常差。

# |4 @/ v+ c7 f3 u/ k# x4 E  L

         经常有各种各样的情况发生，总会让项目改期。

6 H4 R! T3 T* U0 B5 f

+ _, L6 f- G2 k, Q4 r

团队直接管理者

0 Q. |+ [) e. O! P

* L# K& }  p$ Y( H% n, l

• 我非常希望能够快速交付，但我们对这类架构变动类的项目不知道怎么能做到。
  
  

• 这个项目中，有一部份需求必须在XXX时间点完成。
  
  6 M. M; w( L4 E3 i

团队Lead

: m8 J; @$ i0 L$ }+ c

  @! G  G2 x9 _$ a6 |3 E' G0 s

• 估算不准确、临时插入事情多、项目计划很难做（这里省略一千字）。
  
  6 I' ?0 r( }8 [+ l

• 我不知道怎么改进，因为我周围的团队也是这样，而且一直这样工作。
  
  

, L3 W1 U+ b/ H9 Z0 B1 e

开发人员

. r  j. J/ A& J$ W* m5 N

& z! k" y# {0 Q4 J4 o) d

• 领导说试一下，就试一下吧。
  
  ( j" j. E; a: L4 f& e1 T: j. c
  
  

测试人员

) c4 E( e4 Q; P  x

( o% Z8 o8 V  F* z

• 工作经常被打断。
  
  , M' M0 H" X" p+ o7 h, E. u

2 `) J0 N$ e5 o  X$ G8 W

• 提测质量不高，经常浪费精力。
  
  

$ W, n: P! A* R# D7 c9 Y4 \

• 出了Bug，影响太大。
  
  

$ W4 b& T/ _$ Z( U  D. O( ~) a# B

• （这里省略一千字）。
  
  

二、找到正确的问题来解决（目标）

  d& u/ J7 Y6 r! E: P% u( G! R

/ R5 G# w. `/ z( x8 V5 Y

三个月内：

（１）该项目交付时间可预期。

8 Y, t! |( w$ `/ p) C

$ k0 B5 w; h( }8 b

（２）建立新的软件开发协作方式。

  e7 ?. G- C1 f2 p" o% H; ]5 G# x! `

（３）建立必要的基础设施，以支持后续的持续发布模式。

+ ~$ q2 T/ _0 N: F% z

三个月后：

) u5 p% a5 U& d9 u3 ^6 g, [) M

（１）需求的周期时间缩短，可以短周期上线。

& V, y' G1 B: |) q, z" j

（２）生产环境的质量不降低。

* t+ W; A3 y0 N8 B% n+ E. C/ ^7 ^

' _3 m% D! p$ ~1 C: j) {/ u

（３）测试人力总投入降低。

! Z5 G8 V# ^+ G% k( v

4 ~7 N( L3 k& x7 j/ l0 V

在少于30人的团队（61个人也可以～哈哈～那62个人呢～～～）

( v0 a% M( D3 c# x& D

8 j+ r* E2 R# K. ?1 V+ |7 k9 }

1.通常行为的改变，需要一个半月的时间；

% P( ~/ L: I) ?2 ?# n

2.带来强烈可感知的收益需要三个月的时间。

/ A1 x' \% ^$ m0 B9 n

% C) c5 e" K% `

三、承诺是必须的

上面的问题（目标）找到了，也要一并承诺。

* B' B0 b1 C; P1 D0 L5 T4 l/ W: X

( N" F$ k( [, l

要想让团队和你走，你必须站在前面。

  N8 b0 a6 t1 F+ }, f& @

四、培训及过程指导

" ~' Y8 O. U+ {& x

需要解决团队提出的任何疑问，如果当时不知道如何解决，也要承认。

1 B" z4 c6 }9 k0 ?8 x& |

启蒙培训（1小时）

; C3 |% N) a! w6 ]

' E+ R* u$ v& X+ @0 {, o

对于这种能够直接认识团队每个人的小团队，一开始就别花费太长时间讲大道理，以解决具体问题的方式来启蒙。

" Z  I/ J6 N3 ]9 x5 V  ?

: u& m# ?  ]$ O  g, `

重新定义工作流程

3 q, @& B: W7 ?4 |  W, e
6 S( q! U, o+ Y/ [

• 新的项目工作流程
  
  1 q/ y; R, ^) m  d4 L& t; U

% ]4 ~* J: v4 E' ~! }* L, u* `* T, b

• 新的迭代工作流程
  
  

$ I" j" D" x5 c  X! ?

• 新的需求工作流程
  
  ! ~! Z1 _7 Z1 y0 {  m9 G7 \

. [4 k) _) i9 W- [

" m- [: I6 L) l0 A2 |

  j5 ]  O4 L  ~* B

• 新的代码工作流程
  
  

解决新流程中的障碍

• 团队沟通和协作的方式。
  
  5 g/ X; T5 _! L5 ]2 ~

0 m0 Y6 R) V0 v5 _0 Y2 c* @9 w

• 编译环境的准备。
  
  

• 编译时间的缩短。
  
  - f0 d; ^! a5 @- g8 {5 Z1 t

' G' q8 u% l$ a

• 自动化测试策略的制定，比如：我们放弃了原教旨主义的单元测试。
  
  , L" s! l2 g3 G
  
  ; y1 f* c  ~+ s" O2 A

$ x. T; f" B, C' w

• 自动化测试运行的环境的准备。
  
  

• 自动化测试编写时机与自动化的利用。
  
  0 I) _+ u0 b' w+ W$ C

' Y* Q; b. Q- Q( X5 H

• 自动化测试用例代码管理。
  
  : X. @$ g1 s7 W# L$ `4 q6 |

我和运维人员的对话（真实的场景再现）

# [; g3 }. f) H' D

我：我们团队想每两周就部署一次服务

/ q3 J5 n! R* }  q/ J5 r' K

运维：不行

& f0 W. J: `7 n; Y- T/ L

* A5 ]0 M1 c' c1 c9 f& O2 M

我：为啥？

7 S9 q% G7 v, ?8 g  V. n) a

运维：线上需要稳定

% a& ?4 h* ?% @% J

我：每两周部署一次，就不稳定了吗？

" L4 E- V5 w  j) t+ d! S

) |$ k0 G' l4 D5 i

运维：原来的质量太差，每次上线总是出问题

  n# F/ k6 N" W* L6 }/ v: w

我：现在质量很好

* U3 L5 h! [! d3 G/ Q0 }) D' n

运维：怎么可能？

我：我们改变了工作方法，质量优先，你可以参加我们的站会。你有什么要求，我们都可以满足；

运维：那也不行

. l. h; @2 U( t- \2 w

我：为啥

: h1 q1 K; h% s8 F

: U1 @4 h9 F5 X+ Y8 H- Q# p3 v

运维：我没有那么多时间。一次部署要涉及370多台机器。原来三个月上线一次，每次前前后后要折腾两天。现在每两周上线一次，我还哪里有时间去干其它业务线的活啊？

怎么解决？

改变部署方式，让他的工作生活美好起来吧～～～～～

部署流水线的建立，要求一键部署

- ^$ I% ]- F; P; M* t1 N3 |& r$ u

运维人员负责编写部署脚本，并做版本管理。


% O( y7 K$ V2 O+ k% T* Y开发人员在开发自测时使用同样的脚本。
! N: {" Z+ ]# h0 r

  t& [# `3 w$ ?$ I7 \! t5 Y; P! d测试人员在测试环境上使用同样的脚本。


+ [# Q9 ?9 `+ C运维人员在生产环境上也使用同样的脚本。
& X3 F& J6 l$ n  h0 D  D% \

• 原创：乔梁
  

. ]8 M, w- W, A% W; c+ r* s8 e