传统的持续集成 (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 slave 供应。
这些工具允许通过使用推测合并策略来并行测试同一项目。如果同一项目的多个审查同时出现，Zuul 能够通过以推测方式堆叠它们来并行测试它们。例如，如果审查被命名为 A、B 和 C，Zuul 将并行测试 A、A+B 和 A+B+C。如果它们都成功，那么这将与测试和合并 A，然后在分支 (A) 之上测试 B 并合并，以及在 A+B 之上对 C 执行相同的操作相同。当您有多个贡献者参与同一项目时，这会大大加快流程。
Zuul 还能够管理跨项目依赖关系，从而允许在仓库之间合并审查。这在您的组件位于不同 git 仓库的 git 世界中至关重要。
亲自尝试
对于大型团队甚至小型团队，您都可以通过配置前面描述的组件，从这种工作流程中受益。有一些 puppet 模块可以用来轻松配置这些服务。
另一种方法是使用我们自己集成的这些服务，称为 Software Factory。您将获得以下功能
- 在单个 Web 菜单下的良好集成。
- 所有服务之间的单点登录，以及在 LDAP、GitHub 或 launchpad (cauth) 上的外部身份验证。
- 错误跟踪系统 (Redmine)。
- 协作工具
- Paste 用于共享输出或代码片段。
- Etherpad 用于协同编辑。
- 以简单的方式管理从先前版本的升级。
由于 Software Factory 是自托管的（我们使用 Software Factory 来开发 Software Factory），您可以在 softwarefactory-project.io 上看到它的实际效果。
如果您想试用 Software Factory，只需按照 softwarefactory-project.io/docs/deploy.html 上的文档进行操作即可。
请随时告知我们您在使用这种新的 CI 方式方面取得的成就！
6 条评论