问题描述
在讨论中，有人经常提到分阶段持续集成（CI）系统，我觉得有必要写一篇可以轻松参考的文章来解释这是什么。下面是问题：
什么是分阶段持续集成（CI）系统，它与传统的CI系统（即目前存在的大多数CI系统/工具）有何不同？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
传统CI系统与分阶段CI系统的区别
传统的持续集成（CI）系统是一种反应性的系统，它检测回归问题，但需要人为干预进行修复。传统的CI依赖于已经集成的代码上执行自动化质量检查，这些检查是在变更提交/合并到集成分支后（通常由这些事件触发）进行的。这些检查的结果表明集成是否成功，即在该点上，分支是否适合继续进行交付/部署的后续步骤，或者是否出现了回归问题。有些回归问题被认为是灾难性的（例如构建失败），必须尽快修复，因为它们实际上会阻塞分支上的开发。然而，不幸的是，在大多数情况下，修复需要人为干预，这可能是一个显著的瓶颈。
相比之下，分阶段持续集成（CI）系统是一种主动性的系统，它预防回归问题，并在适当的编排下可以完全自动化。分阶段CI在提交/合并到集成分支之前对候选变更执行质量检查。如果检查成功，变更将被自动提交/合并到分支中，理想情况下由CI系统本身执行，无需人为干预。如果检查发现回归问题，并且被认为是灾难性/阻塞性的，候选变更将被拒绝（即阻止其提交/合并到分支中）。因此，分阶段CI系统具有“阶段性”的特点，它会防止“不良”变更甚至进入分支。
一个简单的例子是基于拉取请求（PR）的集成，通过一个或多个自动验证（例如构建和可能的冒烟测试）来连接到PR处理中，必须在PR合并之前成功完成。这是许多开发团队的常见做法。
然而，仅仅拒绝“不良”变更是不足以确保集成分支始终保持最低质量水平的。
良好编排的重要性
有可能同时存在多个候选变更。但是，同时启用多个质量检查（在不同的候选变更上进行）意味着至少有一些检查不会考虑到其他并行进行的变更，这可能会导致由于变更之间的干扰而出现回归问题。
这就是为什么采用上述提到的基于PR的系统时，分支偶尔仍然会出现故障的原因。
这可以通过良好的编排来解决质量检查的问题。编排的目的是通过控制何时启动/停止每个检查以及它们覆盖的候选变更（基于一个或多个输入，可以包括：其他候选提交/当前状态，其他检查的结果，实际提交/合并，检查所需的资源可用性等），从而完全消除变更之间的干扰风险。
一个非常基本的PR基础CI系统的编排算法示例是，只允许在合并时分支的顶端与自动PR验证启动时的相同状态（即在此期间没有其他变更被提交/合并）。这实际上是串行化PR处理，对于小团队可能效果很好，但在大规模项目中可能无法跟上。
编排算法（或缺乏编排）最终决定了分阶段CI系统的可扩展性、性能和维护集成分支质量水平的能力。一个在阻止阻塞回归方面效率达到100%的算法将不再需要人为干预进行正常操作，使用这种算法的分阶段CI系统通常可以完全自动化 – 从一端接受变更候选，通过中段过滤出引发回归的变更，最终在另一端输出保证稳定分支标签的流水线。
值得注意的是，无论是传统的CI系统还是分阶段CI系统，都仅涵盖了集成阶段，并不会对CI/CD流水线的交付/部署部分产生基本限制 – 任何传统的CI/CD工具都可以在分阶段CI的后面进行插入（如果需要）进行额外的（但非阶段性的）CI验证，并进行CD步骤。同样，任何发布策略都可以与其中任何一种一起使用。
注意：对于像git这样的分布式版本控制系统，答案的上下文是主/源/中央存储库，而不是本地副本。