前言

近几年，很多的时间都是在做跟持续集成(Continuous integration，简称 CI)

相关的事情，那么，对于 CI 而言我们改关心的东西是什么呢？

概念

大师 Martin Fowler 对持续集成是这样定义的:持续集成是一种 软件开发实践 ，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。

目的: 在产品快速迭代的过程中同时保证产品的质量。

工具

随着 CI 得到普遍的认知，越来越多的工具出现。Jenkins、Travis、 Codeship 等等的工具被应用到各种的场合里。对于我而言更多接触的是 Jenkins, 以此为例子。

当我们谈论 CI 的时候，很多人的直觉或者说会直接告诉你'Jenkins'。不可否认，Jenkins 的流行度是很广的，丰富的 Plugin 都为我们提供了遍历，但是，CI 等于 Jenkins 吗？ 答案是否定的。

当你接触到 Jenkins 这个平台后，第二个面对的问题是 Pipeline，Jenkins 2.0 之后提供了 2 种 Pipeline 的写法。从工程角度而言，选择哪种都是 OK 的，这里要表达的是，CI 不等于 Pipeline。

误区

在项目团队里，我遇到的一个现象是，团队对使用 Jenkins CI 还是 GitLab CI 争吵了 2 个多星期依然没有结论。为什么会存在这样的现象呢？个人认为，团队过多的关注了工具而非 CI 目的，对工具而言，每个工具都有好坏。如果说我们关注的是目标，那么是否会不一样呢？

作为一个测试开发，很多时候是在满足团队的需要，团队说要做 CI，而 SDET 就提供了这个能力，在这个过程中扮演的角色是'工具人'的角色，来了一个需求就做，我认为这对一个测试开发而言是远远不够的。

CI 需要考虑的事情

市面上有很多的书籍都有介绍 CI 相关的实践，我相应这些的内容一定比我的好。那么，我想说啥呢？对于工具而言，工具的可选性真的很多，选择合适你们的工具。一个工具它会提供很多炫酷的功能，关注点是哪些功能对你是真正有用的，一个很好的功能在你的项目里无法发挥作用那就是 0。

在从事 CI 的过程中，首先，要做的应该是了解分支模型，这是很多人忽略的一点，啥也不懂就开干了，差强人意。 在了解完分支模型后，制定适合你们团队的分支模型，开发模式，基于这个模型建立完整的 CI 体系。在 CI 流程建立的工程中，需要做的情，第一,建立规范，test、build、deploy 都应该遵循一致的规范；第二，建立质量门禁，什么场景 code 才允许被合并到主干，这是非常非常重要的，比如说，在我们的实践中 test 必须是 all pass，增量 code coverage 必须达到 80%。

总结

在 CI 的工作中，不应该是一个工具人，你需要全局的思考哪些是必须的，建立流程规范。