问题描述
作为一个大型（40+开发人员）的老旧（16+年历史）软件项目的开发者，你们使用SVN作为源代码控制工具，并且正在进行自动化。但是有一个问题困扰着你们，那就是有40名开发人员在将代码提交到主干(trunk)时，无法完全运行所有测试。你们的测试套件包括JUnit单元测试、运行在应用服务器内的JUnit集成测试，用于测试业务流程的黑盒测试工具测试。单元测试需要10分钟，集成测试需要40分钟，而黑盒测试需要整夜运行。由于无法运行所有测试，经常在CI环境上出现测试失败（至少有个CI环境可用！）。由于有40名开发人员同时进行开发，导致很难确切知道测试失败的原因。”是我造成的吗？我只是修改了应用程序的其他部分。这不应该是问题吧…?”你想推广基于分支的开发流程，希望能在将分支合并到主干之前对其进行测试。虽然考虑切换到Git，但并不固执。目标是主干(trunk)始终保持绿色状态。但为此，你需要一个能支持多达60个分支的基础设施。
你构想了一个分支构建服务器池的系统，每个团队都可以请求构建和测试某个分支（可能是指定的修订版本/提交ID），所有构建请求都进入队列，并由构建服务器群进行处理。（目前我们的问题是可用硬件不足，无法扩展构建基础设施。在我看来，池化现有硬件似乎是最好的方法。）
你想知道对于这个方案，大家有什么看法？你如何实施这个方案？Jenkins的多分支流水线（https://jenkins.io/doc/book/pipeline/multibranch/）是否是正确的路径？
你是否走错了方向？你知道CI要求每个人每天至少向主干(trunk)提交一次。但是，当40个开发人员一起提交时，会产生很多副作用，而且软件（特别是数据模型）不能防止应用程序各部分之间的副作用。你必须从某个地方开始。但从哪里开始？
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在你的情况下，为了保持主干的稳定性，分支的验证必须是完全串行的。这意味着如果你想要主干始终保持绿色状态，分支验证（至少是那些允许分支合并到主干的成功验证）需要考虑以下几点：
– 分支验证开始时，不能有任何其他类型的更改进入主干（假设在验证开始时最新的主干更改已合并到分支）并且在分支合并回主干之前。
– 如果验证期间有任何其他更改进入主干，这些更改将不被考虑，当分支合并回主干时，可能导致破坏。要防止这种情况，你需要再次将主干合并到分支，以获取最新的主干更改，并重新运行验证。
实际上，这意味着如果你想要支持所有的集成测试（40分钟一次），最多可以支持约60个分支（假设合并是自动化的，可以全天候运行，这并不简单）。如果合并不是自动化的，分支数量会少得多。这种方式无法扩展，分支的生命周期会逐渐增加，逐渐偏离持续集成，并最终对你的团队造成压力。
同样的逻辑也解释了为什么开发人员不需要运行所有测试，如果测试太耗时 – 在完成测试时，结果可能会被其他提交到主干的更改所无效。此外，由开发人员执行的测试结果通常并不那么相关（”但是在我的工作空间中构建正常!”）。
在这种情况下，有两种方法（据我所知）可以获得相关的验证：
1. 传统CI工具执行的验证 – 在将更改提交到主干之后执行，反映了实际主干的现状，包含所有集成的更改。唯一的问题是，如果这些验证失败，实际上会阻止在主干上进行进一步的开发，直到找到问题的原因并修复回归。在较大规模的项目中，这可能会很困难，正如你已经注意到的那样。
2. 由门控CI工具执行的验证 – 我只知道两个工具支持这种方式：Zuul和ApartCI（后者是我的项目）。这些验证在将更改合并到主干之前执行，但是以协调的方式，确保它们始终保持相关性 – 同时考虑所有其他正在进行的更改，这些更改最终将在某个特定更改被合并到主干时出现在主干中。这个过程完全由CI工具自动化执行