实践者的 DevOps 之路(3. 持续集成 CI)

在上一篇中我们谈到了分支模型，如果说分支模型是 DevOps 实践的开始，那么 CI 就是 DevOps 核心实践，没有 CI 保障的 DevOps 无异于盲人骑瞎马，承担了巨大的风险却没有任何的收益。那么如何开始 CI ，如何确保 CI 在 DevOps 中发挥更好的作用，从而推动整个 DevOps 的进步呢？希望本文会给你一些帮助。

自动化

CI 的第一步应该将你项目整个构建的过程自动化，典型的 CI 流程至少包括以下几个步骤：

从源码仓库签出最新的代码
静态分析，检查最新的代码是否存在潜在的 bug 并符合项目的编码规范
编译源码
运行单元测试
运行集成测试
打包

自动化的优点毋庸置疑，能够极大的提升项目效率，将开发运维人员从繁琐的手工操作中解放出来，并且大大降低出错的概率。

很多项目中运维人员通过自己编写 shell 脚本来完成项目的自动化集成，这的确比完全手工执行好了很多，但是这仍然远远不够。首先 shell 脚本是依赖于某个操作系统环境或是某个特定的 shell 版本。其次，shell 脚本相对不易维护，如果没有把 shell 脚本放入版本管理中，那么当项目越来越复杂后，shell 脚本本身也就很难管理，非常容易出错了。因此在 CI 自动化的过程中我建议采用以下的一些实践：

使用 Jenkins 这样的工具管理整个 CI 流程
使用类似 Jenkinsfile 的 DSL 配置项目的构建流程
尽量使用 Python 这样的高级语言运行构建的各种任务，或者使用 Ansible 这样的框架管理基础设施
将所有的 CI 相关的代码都放入版本管理中，视为与源代码相同的资产

理想状态下 CI 的第一阶段应该做到「一键集成」：点击 CI 系统中的按钮就会完成所有的 CI 任务，生成可以发布的二进制包。这才是自动化应该有的状态。

CI 的频率

自动化带来的另一项优点就是我们能够随时触发 CI 的运行。从系统化思考的角度来看 CI，CI 其实带来了的是快速反馈的循环。当项目的任何一点发生变化时(例如源码，配置参数，依赖的第三方类库等)，就应该触发 CI 的运行，检查整个项目是否正常。

参考之前提到的实践者的 DevOps 之路(2. 迈出第一步: 分支模型)，如果我们使用类似基于主干开发的分支模型是，应该将 CI 运行的时机与 commit 挂钩。即每次代码的 commit 都应该触发 CI 的任务。这样做的目的在于最小化的反馈当前项目的健康状态，让整个团队不会偏离主航道。而不同分支之间的 PR 合并也应该触发 CI 的执行，原则就是当某个分支上的代码发生更新时就应该立即触发 CI。

从上面可以看到，代码提交的频率对 CI 也是有一定影响的。如果整个团队的 User Story 的粒度不合理，或者程序员的开发习惯不好，总是集中，一次性的提交大量代码，那么 CI 的效果也会大打折扣。因此在开始实践 CI 的同时不要忘了在团队内普及开发的最佳实践和良好习惯。

为什么我的 CI 没什么效果？

很多项目中，客户一开始就告诉我，我们是有 CI 的，每天都要集成好几十次，但是效果却差强人意，并没有很好的提升项目交付的质量。在深入查看客户的 CI 之后，我发现问题的答案很明显：缺乏足够的自动化测试！

从下图看一个典型的 CI 构建流水线，我们不难发现自动化测试是必不可少的一个环节，我个人认为应该是 CI 中最重要的一个环节。如果抛开测试，你的 CI 到底做了些什么呢？静态分析，编译，打包？并不是说这些不重要，只是自动化测试提供了更多的价值。

思考一下，自动化测试为你的项目提供了一张「安全网」，任何一点项目上的变动都会触发这些测试用例的执行，作为某种形式的回归测试，可以让你不必担心新功能的引入导致新的缺陷。大部分的技术管理者往往只关注与是否使用 CI，却疏忽了 CI 的核心价值与所需的基础支持。如果没有一个覆盖率较高的自动化测试保障，CI 的价值会大大降低，并不能起到应有的作用。

如果发现自己的项目已经有了 CI，但是交付质量仍然堪忧的话，不妨检查一下自己的单元测试是否足够，集成测试有没有自动化，可能这才是 CI 背后的真正问题。

不要让 CI 沦为「摆设」

项目实施 DevOps，CI 的初期，许多原因都可能造成 CI 的构建失败。比较常见的是因为增加了对代码规范的静态检查，而开发人员在初期无法适应，提交的代码不符合编码要求，从而导致 CI 构建失败。

当项目遇到频繁的 CI 构建失败时，我们应该像精益中所提倡的，在出现缺陷时果断的「拉灯」。要求造成构建失败的开发人员在修复问题的前提下再开始手上的工作，修复 CI 的失败永远是团队优先级最高的任务！

我在许多项目中都曾见到过形同虚设的 CI，构建的界面永远是红色的，没有人关心 CI 究竟出现了什么问题，最终 CI 沦为了一个自动化的打包工具。此时的 CI 已经陷入了所谓的「破窗理论」，当构建失败对于整个团队而言已经见怪不怪的时候，CI 已经丧失了它存在的意义和作用。因此作为技术管理者，应该让整个团队意识到 CI 失败的重要性，要求无论何时 CI 都应该保持绿色。