以review 系统为关键的新一代持续集成

　传统的持续集成(CI)系统被设计成作业的流水线。你可以有一个同行评审，然后开始构建作业，然后是单元测试作业，然后是集成测试作业，然后是性能测试作业，诸如此类。

 

　　每个作业都是由前一个作业的成功完成事件触发的，而第一个作业则是由版本控制系统中源代码文件的变更事件来触发的。当然，如果你的目标是多个二进制平台，或者如果你正在构建的是一组组件，以此来测试整个的应用程序，那么它还会更加的复杂。

 

　Continuous Integration flowchart

　　那么如果有任务失败了会怎样?Jez Humble 和 David Farley 在持续交付中认为，你首先需要遵循这样的原则："不要在失败的 build 上提交代码"。换句话说，不要由于新的提交导致问题更严重。如果你违反了这个原则，你就没法确认引起错误的真正原因。Humble 和 Farley 建议选择下面两种策略之一来处理 build 失败的情况：

 

　　"当 build 失败是，不要去做别的事情，" 意思是团队中的所有人都要停下来去修复这个问题。

 

　　"时刻准备回滚到上一版本。" 回滚的策略可以避免打断整个团队的工作。

 

　　当然，也可以采用混合的策略：在可容忍的时间内尝试修复，超过时间则进行回滚。

 

　　还有一种方式可以稍微缓解问题，那就是使用集成分支，只有集成分支是绿色的(所有测试通过)，才允许进行代码的合并。这种策略下集成分支还是有同样的问题，不过 master 分支可以保证总是可用的。

 

　　类似的方式适用于小团队，你可以让团队的所有成员都暂停代码的提交，不过即使是小团队，CI 处于红色状态也有可能会持续比较长的时间。对于这种方式的 CI 实践，你需要严格遵循完善的规定。不过你也可以尝试一种新的实施 CI 的方式。

 

　　新一代的 CI

 

　　目前的 CI 是以 CI 服务器为中心。CI 服务器负责发现改动并触发任务。

 

　　新一代的 CI 则是以代码 review 系统为核心，这样可以保证在改动合并到版本管理系统之前完成相应的操作。

 

      

 

　　是否加入团队的代码 review 的过程，这取决于你。我强烈建议通过代码 review 来提高代码的质量，但是这与 CI 系统本身是独立的。我们需要强调的是，构建和测试这些行为是由代码 review 系统的新提交来触发的。当所有测试都通过后，代码才会被合并到主干上。如此一来，主干的代码总是可以保证是测试通过的，开发人员也可以并行的进行代码提交。新的 CI 体系可以让你的自动化变得流畅，因为不再有问题会阻塞流程。

 

　　OpenStack 的工作流程

 

　　CI上的新的方法已经在 OpenStack 项目中得到大规模的实现，一次来管理所有不同的子项目的CI过程。为了使你对它的规模有一个概念，可以看到每天 OpenStack 都要处理 1000 个提交的补丁包，7500条提交的有关于Gerrit的评论和投票， 催生出16,000 个测试环境，还有250次变更的合并(源代码)。

 

　　为了实现下一代的CI系统，OpenStack项目使用下面这些组件：

 

　　Gerrit, 代码审查和git资源库管理器。

 

　　Zuul, git代码库控制系统。

 

　　Jenkins, 持续集成服务器。

 

　　Nodepool, 部署在OpenStack云上的智能的 Jenkins 衍生工具。

 

　　这些工具通过使用随机推断的合并策略来实现在同一个项目上的并行测试。如果同一时间在同一项目之上发生了多次评审，Zuul就能够以随机推断的方式将它们放到一起来对它们进行测试。例如，加入评审被命名为A、B和C，那么Zuul将会并行的对 A、A+B以及A+B+C进行测试。如果他们都成功了，那么就已经跟A经过了测试并进行了合并效果是一样的了，然后B在分支(A)的基础上经过了测试然后进行了合并，C在A+B的基础之上也同此理。 这样当你同一个项目有多个代码贡献者时，集成的过程会加速不少。

 

　　Zuul 还能管理跨多个项目的依赖，允许资源库间评审的合并。这在git中是个关键的东西，因为在git中你的组件存在于不同的git资源库中。

 

　　试一试

 

　　对于大的团队甚至是小的团队来说，你都可以通过配置前述的组件来使项目受益于这一工作流程。Puppet 模块就能用来轻松的配置这些服务。

 

　　另外一种方法就是使用我们自己对这些服务的集成，叫做软件工厂。你将会获得下面这些功能特性：

 

　　对这些功能做了一个不错集成的一个 web 菜单。

 

　　一个在所有这些服务间轻松进行单点登录的方案，还有在 LDAP、GitHub 或者登录面饭(cauth)上的外部认证方案。

 

　　一个bug跟踪系统(Redmine).

 

　　协作工具： 用于共享输出或者代码提取的 Paste。

 

　　用于协作编辑的 Etherpad。

 

　　以一种简单的方式管理从之前版本的升级。

 

　　因为软件工厂是自托管的(我们使用软件工厂来开发软件工厂), 你可以在 softwarefactory-project.io 上对它进行了解。

 

　　如果你想要测试驱动的软件工厂，只要按 softwarefactory-project.io/docs/deploy.html 上的文档照做就行了。

 

　　你可以就使用这一新的方法进行 CI 的收获同我们保持交流。