传统的持续集成 (CI) 系统被设计为作业流水线。您需要进行同行评审，然后是构建作业，然后是单元测试作业，然后是集成测试作业，然后是性能测试作业，等等。
每个作业都由前一个作业成功完成触发，第一个作业由版本控制源代码文件的更改触发。当然，如果您要面向多个二进制平台，或者您正在构建一组组件以便能够测试完整的应用程序，则情况可能会更复杂。
但是，当作业失败时会发生什么？根据 Jez Humble 和 David Farley 在参考书 持续交付 中的说法，您首先必须遵循以下规则：“不要在构建失败时提交代码。” 换句话说，不要通过推送其他更改使情况变得更糟。如果您这样做，您将无法知道故障的原因。Humble 和 Farley 建议使用以下两种策略之一来处理故障
- “永远不要在构建失败时回家”，这意味着团队中的每个人都需要停止处理当前的任务，转而解决问题。
- “始终准备好恢复到之前的版本。” 回滚也可以是避免阻止整个团队的策略。
当然，也可以混合使用：限定修复尝试的时间，然后在超出允许时间时回滚。
另一种缓解此问题的方法是使用集成分支，仅在集成分支为绿色（所有测试都通过）时才合并修改。使用此策略，您在集成分支上遇到相同的问题，但是您的主分支始终处于可用状态。
这在小型团队中可能有效，当您可以阻止所有队友提交代码时，但即使在小型团队中，此过程通常也会导致 CI 长时间处于红色状态。您需要强制执行良好的纪律才能在这种 CI 中取得成功，或者您可以切换到新的 CI 方法。
下一代 CI
当前一代 CI 以 CI 服务器为中心。更改由 CI 服务器检测并触发作业。
在下一代 CI 中，系统以代码审查系统为中心，以便能够在修改合并到版本控制系统之前执行操作。
是否实施队友代码审查流程的决定取决于您。我真的建议这样做以提高代码质量，但这与 CI 系统是正交的。无论如何，重要的是要理解，构建和测试的触发是由向代码审查系统提交的新内容完成的。一旦所有测试都通过，代码就会合并到主分支。这样，您的主分支始终是绿色的，您的开发人员可以并行处理他们的修改。这种新的 CI 系统使您可以扩展自动化工作并保持流畅，因为不再存在阻塞问题。
OpenStack 工作流程
这种新的 CI 方法已在 OpenStack 项目中大规模实施，以管理所有不同子项目的 CI。为了让您了解规模，OpenStack 每天处理 1,000 个建议的补丁集，在 Gerrit 上发布 7,500 条评论和投票，生成 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，然后在分支 (A) 之上测试 B 并合并，以及在 A+B 之上测试 C 相同。当您有多个项目贡献者时，这会大大加快流程。
Zuul 还能够管理跨项目依赖项，从而允许在存储库之间合并审查。这在 git 世界中至关重要，在 git 世界中，您的组件位于不同的 git 存储库中。
亲自尝试
对于大型团队甚至小型团队，您可以通过配置前面描述的组件，从这种工作流程中受益于您的项目。可以使用 puppet 模块轻松配置这些服务。
另一种方法是使用我们自己集成的这些服务，称为 Software Factory。您将获得以下功能
- 在一个 Web 菜单下的良好集成。
- 所有服务之间的轻松单点登录以及 LDAP、GitHub 或 launchpad (cauth) 上的外部身份验证。
- 一个错误跟踪系统 (Redmine)。
- 协作工具
- 粘贴以共享输出或代码摘录。
- Etherpad 用于协作编辑。
- 以简单的方式管理从以前版本的升级。
由于 Software Factory 是自托管的（我们使用 Software Factory 开发 Software Factory），您可以在 softwarefactory-project.io 上看到它的实际效果。
如果您想试用 Software Factory，只需按照 softwarefactory-project.io/docs/deploy.html 上的文档进行操作。
请随时告知我们您在使用这种新的 CI 方法后取得的成就！
6 条评论