持续集成和交付流水线的8个反模式

salala

. `$ z6 h! q% ^! C6 M" f

一、CI/CD & Pipeline

$ q) v3 B4 m1 o

随着DevOps的理念在众多公司的采纳，CI/CD也渐渐落地。
1 H% C  K& g/ o

( Z0 {1 o  I7 f+ H8 p7 S# R

• CI（Continuous Integration）持续集成，是把代码变更自动集成到主干的一种实践。CI的出现解决了集成地狱的问题，让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过一系列自动化测试，比如编译、单元测试、lint、代码风格检查。
  1 Z3 d+ U4 m8 A

0 L  w6 Z* L6 P, u

• CD包括持续交付和持续部署。持续交付（Continuous Delivery）指的是团队自动地、频繁地、可预测地交付高质量软件版本的过程，可以看做持续集成的下一个阶段，强调的是无论代码怎么更新，软件都是随时可以交付的；持续部署（continuous deployment）更强调的是使用自动化测试来保证变更的正确性和稳定性，以便在测试通过后立即部署，是持续交付的更进一步。二者的区别是，持续交付需要人为介入，需要确保可以部署到生产环境时，才去进行部署。
  # X# L3 C: U. N

# e2 @* `( J3 z0 B' n) }CI/CD Pipeline是软件开发过程中避免浪费的一种实践，展现了从代码提交、构建、部署、测试到发布的整个过程，为团队提供可视化和及时反馈。Pipeline推荐的实施方式是，把软件部署的过程分为不同的阶段(Stage)，其中任务(Step)在每个阶段中运行。
; t; \4 [  I; X/ j* p+ {8 G
在同一阶段，可以并行执行任务，帮助快速反馈，只有一个阶段中所有任务都通过时，下一阶段的任务才可以启动。比如图中，从git push到deploy to production的整个流程，就是一条CD Pipeline。可以利用Pipeline工具，如Jenkins、Buildkite、Bamboo，来帮助我们更方便的实施CI/CD。

% B4 t. y& ?* s/ L

二、CI/CD Pipeline的反模式

虽然有Pipeline广泛的应用，但我们却会听见开发人员抱怨糟糕的Pipeline对他们的伤害，如阻塞开发流程，影响变更的部署效率，降低交付质量。我们收集了项目上经常出现的Pipeline的八大反模式，按照出现频率排序，分别阐述这些坏味道，分析可能产生的原因、影响及解决方式，希望能够减少抱怨，让Pipeline更大程度上提升工作效率。
7 z' B8 b& t' I1 h/ h1 g: H" g9 W
2.1 没有代码化


* T1 C6 {( B" F  b5 i$ I, f反模式

1 M* }% {; J+ R* m' i8 T# t+ h
Pipeline的定义没有完全代码化，进行版本控制，存储在代码仓库，而是在Pipeline 工具上直接输入shell脚本定义Pipeline的运行过程。
" S  Y  x8 D/ `5 o9 k! q, f; b
: a6 T* S% w1 g5 D, [
原因


由于早期的CI工具不支持代码化，一直能够保留到现在，没有做重构和升级。


. }6 U) o5 Z  N% J$ m影响
  g& K2 ]+ D4 z( X8 n/ k3 a1 W2 q
0 |: [1 C9 {# U; Z7 l0 M
! |3 o6 x# y6 c5 @' ZPipeline的创建和管理都是通过CI工具的界面交互来的，难以维护，因此需要专门的管理员来维护，而有人工操作的部分就会出错，因此会降低Pipeline的可靠性。如果Pipeline因为一些原因丢失就没有办法很快恢复，就会影响交付速率。
! `7 e6 i3 K' f$ d( R) y

6 z: ^! o3 k# A) s+ d解决方案
9 }  k+ G* ], n& B( Q
- K% g- k/ i, }
. F$ n# T8 S/ Y4 ~/ f+ T6 RPipeline as code这个理念已经提了很多年了，在ThoughtWorks 2016年的技术雷达里就已经采纳了，需要强调的是，用于构建、测试和部署我们应用程序或基础设施的交付Pipeline的配置，都应以代码形式展现。随着组织逐渐演变为构建微服务或微前端的去中心化自治团队，人们越来越需要以代码形式管理Pipeline这种工程实践，来保证组织内部构建和部署软件的一致性。

通常，针对某个项目的Pipeline配置，应和项目代码放在项目的源码管理仓库中。同业务代码一样要做code review。这种需求使得业界出现了很多支持Pipeline工具，它们可以以标准的方式构建、部署服务和应用，如Jenkins、Buildkite、Bamboo。这些工具用大多有一个Pipeline的蓝图，来执行一个交付生命周期中不同阶段的任务，如构建、测试和部署，而不用关心实现细节。以代码形式来完成构建、测试和部署流水线的能力，应该成为选择CI/CD工具的评估标准之一。


* W1 o/ r" a* M: M2.2 运行速度慢

  ?" X8 [  O* ~3 m2 _
反模式
& {8 a* X& E. N  M; t  r) @2 Z+ m% p
( {8 K$ a7 {: i- t& _8 s
  v3 y/ l7 i! @# v' Q一条Pipeline的执行时间超过半小时，就属于运行速度慢的Pipeline。（这里的运行速度与交付的产品有关，在不同的项目中，运行时长的限定也有所不同）

# L3 g2 h, }' |
原因


$ {+ |2 R* C; D; K很多原因都会导致运行一次Pipeline时间很长，比如：

• 该并行的任务没有并行执行，等待的任务拉长了执行时间；
• 执行Pipeline的agent节点太少，或者性能不足，导致排队时间太长，效率太低；
• 执行的任务太重，相同测试场景被不同的测试覆盖了很多次。比如同样的逻辑在不同测试中都测了一遍；
• 没有合理利用缓存，比如每个任务里都要下载全部依赖，在构建Dockerfile时没有合理利用layer，每次都会构建一个全新的image。
  

9 |4 `/ V' W2 [2 K
影响


- D- a4 k! d9 o* S* V这是开发人员抱怨最多的一个反模式。敏捷开发模式需要Pipeline快速反馈结果，受这一反模式制约，在特性开发过程中，经常出现开发人员改一行代码，等半天CI的效果。如果出现一个线上事故需要修改一行代码来修复，最终需要很长的周期才能让这一更改应用在生产环境。
+ b) p$ v  D: W! V, ~
$ O4 E0 z5 l( g( j+ l
解决
% m, F* _2 X+ p* B
7 w* M' S0 I0 J2 F' b7 @: t
. S( M2 U5 t" C, R6 H4 k不同的原因导致的Pipeline速度慢，有不同的解决方法。比如针对上面的问题，我们可以去：
  t: w" h5 l* Y7 {0 H7 w9 y  i

• 检查Pipeline的设计是否合理，尽可能让任务并行;
• 对代码的各种测试深入了解，让测试尽量正交，避免过多的重复；
• 检查代码中的依赖，合理利用好缓存。包括Docker Image、Gradle、Yarn、Rubygem的缓存，以及Dockerfile是否合理的设计，最大化的将不可变的layer集中的开始阶段；
• 检查执行构建的节点资源是否充足，能否在任务量大时做弹性伸缩，减少等待和执行时间。
  + u# Z4 ~" v: k8 z: x% @

3 ~5 h' r# f- {9 u+ P1 b' M% Y
% r& H& C7 h0 j  x9 [4 K1 o2.3 执行结果不稳定
8 h! ?; {% V. A9 U: E5 @3 y% q' N  W

7 I8 k! S# c  [  j) L/ M+ X

$ n& w( C4 ~4 B3 w

图3 执行多次结果不稳定

0 H% v% H+ P$ J+ T4 M
反模式
/ A7 x; Y) e* n: m
2 g! x& T1 |1 c0 k9 ]( `
构建相同代码的Pipeline运行多次，得到结果不同。比如，基于同一代码基线，一条Pipeline构建了5次，只有最后一次通过了。


原因

7 P5 b! C! |) L8 O+ ^
出现执行结果不稳定的原因也多种多样，比如测试用例的实现不合理，导致测试结果时过时不过；代码中使用了不可靠的依赖源，比如来自国外的依赖源，下载依赖经常超时；由或是在Pipeline运行过程中没有合理设计各个阶段，导致有些任务同时运行冲突了。
: a0 N. ]( H5 C' V' {

影响
0 Y. v% z. U, g8 C5 ^
, [7 E8 r" B  Z7 C8 Z/ p# y$ w- x
Pipeline作为代码发布的最后一道防火墙，最基本的特性是幂等性，即在一个相同的代码基线，执行Pipeline的任意任务，不管是10次、100次，得到的结果都相同。Pipeline不稳定会直接导致代码的部署速率降低。更重要的是，影响开发人员对Pipeline的信任。如果不稳定Pipeline不及时解决，慢慢这条Pipeline会失去维护，开发最后会转向手工部署。
) A# I) A0 }0 W7 ~* I% ?
- {7 k! O. m* c# e. i: s. U
6 D$ _5 ]" I( B解决


# I9 {' g, R1 n7 W3 `1 N& u要构建幂等的、可靠的Pipeline，就要分析这些不稳定因素出现的原因。

• 提升测试的稳定性，比如用mock替代不稳定的源。
• 采用Pipeline的重试功能，或者采用稳定的镜像源，或者提前构建好基础镜像。
• 引入Pipeline的插件保证任务不会并行执行。
  

2.4 滥用job处理生产环境数据
, g  i0 U+ f1 l

' E" D6 N5 L; }3 x( b反模式

7 ]7 [) W' v6 p# r8 F
5 ^8 \; P3 y+ N! F使用Pipeline的定时任务的特性，运行生产环境的负载。比如经常会定期做数据备份、数据迁移，数据抓取。
/ b& y$ ^$ w& T9 ?# w! |, D

原因
4 t; }$ v" \+ i1 H% i9 A
; j, T2 g9 p% B! u
由于对Pipeline的认识不够清晰，将重要的任务交由Pipeline做。Pipeline一旦有了某个生产环境的访问权限，做这些数据处理相关的任务就很方便，减少了很多人为的操作。
5 Z# D4 l& p2 t2 K3 i" `8 s

% m3 l9 [* g) Z3 p1 Y影响
1 i/ J' ~6 {$ G  P- L

Pipeline是用来做构建、部署的工具，不能用于业务逻辑的执行。由于Pipeline是一个内部服务，他的SLO/SLI必定和生产环境不同，如果强依赖势必影响生产环境的SLO。假如某天Pipeline挂掉了，生产环境就无法得到想要的数据。另外，任务和Pipeline紧密耦合，是我们后面会讨论的另一个反模式。


( e" Q$ w9 [$ P2 \  g3 a解决
& i3 ~# q& ~9 n& Y. h$ m

6 I- M! w. K( x5 K' w! F方法用生产环境自身的工具解决这种数据问题，比如 采用AWS的lambda，定时触发数据处理任务。
" f5 m( |! T$ V' T) C! q

' C3 S4 B3 {9 @/ A+ |2.5 复杂难懂
" H% X7 s& z, k2 |- x5 K
; n/ s  i$ q3 E$ V0 N4 _0 b
' Y/ J" `4 i$ Y+ k; L

2 H$ ?% X8 O3 l0 v; z* F4 d7 l9 W

! z$ d+ c" U$ k: V- L反模式
* [. ~% F# c( A) r9 F3 b6 ^' _

Pipeline的定义包含了太多的逻辑，复杂难懂。只有在一条Pipeline运行起来才能知道这里会运行哪些步骤，会将这个版本部署到哪些环境。


/ h9 V0 z- _; a5 C) p3 a9 I原因
6 N+ G" r& \1 L& E: z

- g0 V# k1 u. x6 W& p7 nPipeline的代码不够整洁。有人认为Pipeline只是给CI工具提供的，就随意编写，认为能完成指定的工作就够了。
. C* {( w% j+ \+ H

& W$ S) ~( o: K影响

  y& j3 Q  ^2 I  G. ]
Pipeline的复杂性，会直接提升学习成本。如果想重复执行上一次构建，会花费较长时间。
5 Y0 S$ P7 _/ G% @

4 c$ [6 q6 u. L解决
1 n5 I0 s; }& u0 q

Pipeline的代码要简洁，把复杂性放在部署脚本或代码侧。通过每个阶段的的标题可以直接了解所要执行的任务。如果存在很多相同的逻辑，可以通过开发Pipeline的Plugin来简化配置。
+ q9 x+ Y" D+ @2 t
/ s* t8 i+ r& H( }/ I3 `; i
7 L7 f8 Z1 t' I% \3 F2.6 耦合太高

6 Y  F4 }7 B# ^, R3 {- ?# e' W
0 b. [4 f( \8 F' p/ |1 e

) c, R9 ]$ H2 i4 s8 w! G反模式
4 D! [; E/ F: K+ z8 b' _

Pipeline跟运行它的CI工具紧密耦合，以至于无法在本地重复相同的步骤。表现可能多种多样：

• Pipeline的定义跟构建工具紧密耦合，包含了Pipeline工具特有的参数以及CLI命令。比如在配置中使用BUILDKITE_BUILD_NUMBER，BUILDKITE_QUEUE等等。结果就是本地运行的方式或结果和Pipeline上运行的方式以及结果不一致。
• 在Pipeline的任务中写了一大段脚本，或者直接使用命令加上一堆参数，以至于在本地想跑测试需要在Pipeline的配置中找命令并且在本地粘贴。
• 不做环境隔离， 测试，编译，部署等都依赖于运行时环境。可能出现Pipeline 因依赖的软件/库等版本不一致而导致的不一致的情况，通常还很难排查。
  

影响
6 e3 z8 k$ X8 @* s% R5 D" N" o6 P
* O: h( l7 O! n. ?) `, j4 ]$ |& A4 G
% o% b( A' E8 Y6 t因为本地不方便调试，所变更的失败概率会大大增加。如果变更用来修复一个Bug，由于不做环境隔离，会导致故障修复周期拉长。
" }% u- c/ ^9 G7 f9 |
& N0 A0 R& G9 b" |
解决


* m4 V) q6 e- Y! I3 f# k2 B9 ePipeline的每个step都用脚本封装起来，脚本里不使用Pipeline工具特有的参数，并且保证本地运行时和Pipeline上保持一致。

3 f. E+ O; n* l- O
% `1 s! P) l, S& S7 c+ A: n2.7 僵尸Pipeline

: t; ~5 a7 I6 F% V# v; P# c. t
反模式
/ M8 F7 j" r) B$ C  w9 H9 ]

一条Pipeline年久失修，很久没有执行过，而且最后一次的构建是失败的。

5 ^  {' O5 Z# F" [* {. k, [
3 f4 |! Q0 y' @原因

' I; m- j: ~& S/ r6 `
& |% Q" \2 @& s3 e这种反模式通常出现于不再活跃开发的项目上，因此很久没有执行过Pipeline。
# E! ]9 f* d1 w5 E3 S! j, M

影响
% e8 s1 S% h% G' \' u
2 V. \" F$ w! [$ S
Pipeline的结果反应的是一个项目的状态。由于软件产品迭代速度快，这个软件的依赖可能已经发生了巨大的变化，一旦运行，大概率会出错。假如这个项目目前出现了一个事故，需要提交代码，就得先修复项目的Pipeline，才能确保提交修复代码。
) V! H( w+ f' {# V) Q

! I+ }% y0 g" Z: P* \, z$ P解决
2 ^5 O' `' _( N
' \. R; b4 k; }+ L( b$ y  ]/ @7 E
: R: X+ f* T3 B% l! j& }! W: ~! U& b针对常年没有提交的Pipeline，我们建议让Pipeline周期的执行，出现问题立即修复。如Github的Dependabot，能保证项目的依赖始终是是最新的，而且能让Pipeline执行，提早发现问题。

' N( x/ ?9 j7 u! z( ]/ a
. u& d3 S7 ?0 V1 C& v" E# N# ]5 x2.8 需要人工介入


# z% ?, f. X% @. U反模式

, ]# f7 Y4 \" n  T1 `
通常项目上会有一个专职Ops，在项目可以发布的时候手动触发部署流程，或者需要传递很多参数，让Pipeline运行起来。


原因

2 w* y; _' L3 W' d* w
9 E: A# x5 |4 A2 d+ A包括项目的流程繁琐，需要反复确认；DevOps成熟度不够，没有实现持续部署；或者CI的测试覆盖不够，CI通过后还要进行更多的测试才能部署。
: W5 y- e) f+ H' Q- U( j

影响


这些Pipeline需要专人盯着，去点某些按钮。会直接影响产品的交付速率和代码部署频率。

5 ?( c  I4 U; \: M; H
解决

# ~7 o8 C0 [0 y9 x  F1 R% R5 w
4 H2 F# a# h  O让项目的运行更加敏捷，减少Pipeline定义中的阻塞按钮，将手工测试自动化后集成到Pipeline中。

最后

希望通过本篇文章，意识到项目中CI/CD Pipeline的问题，使其发挥更大的价值。（来源：Thoughtworks洞见）
$ e6 {% g' q5 T
/ y3 c4 W' h+ f& W

9 g3 O2 Z2 t/ h& L5 s% A, o