传统的持续集成 (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 仓库的世界中至关重要。
亲自尝试
对于大型团队甚至小型团队，您都可以通过配置前面描述的组件，从这种工作流程中受益于您的项目。有一些 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 条评论