随着在同一分支上工作的开发人员数量的增加，破损/堵塞的风险也随之增加。最终达到了一个平均水平，即在修复破损时平均出现了一个新问题–分支上的进展实际上可以忽略不计。
分成多个团队，每个团队在一个单独的集成分支上工作，这将是稍后合并可能会有所帮助，但会大大延长项目的持续时间，因为它只会延迟稍后的必要集成，同时会增加与各个分支合并中的部分集成相关的客户流失/噪声/技术部门。由于每个分支机构都设置了CI，每个分支机构都有自己的构建/ QA资源等，因此成本也会增加。总体质量不一定更高。
可扩展性充其量是可疑的。 />
是否有一种方法可以使如此大的项目实际规模化？
#1 楼
是的，但这是通过尽可能避免您在问题中提及的事情。您是对的，只有那么多开发人员可以在无法控制的情况下使用相同的代码。您需要可以概述所有更改并确保集成正常进行并且不会发生回归的人员或事物。如果一切都发生在一个存储库中，这很难扩展。
开始任何工作之前，您需要以一种方式分离功能的方式，以便以后可以轻松地集成东西。
意味着您希望将功能划分为独立的部分，或者至少要尽可能少地依赖。
如何执行此操作很大程度上取决于您所开发的产品。过去，功能的分离是通过创建不同的库来完成的。缺点是您需要一种管理这些库的好方法。例如，旧版本的Windows有一个错误的库管理系统，导致臭名昭著的DLL地狱。
如今，微服务已成为一种流行的方式，尽管这样做也有其缺点（例如，通信开销，更多要监视的服务）
如果难以基于功能进行分离，则另一个选择可能是及时分离开发。与让多个团队同时处理许多不同功能不同，您只有一个团队一次只能处理一个或几个功能。
如果无法分开工作，则需要使用工具和确保事物对齐的测试。自动化的单元和集成测试可以在这里起到很大的帮助，但是最终一个项目或团队的规模将受到限制。
#2 楼
随着在同一个分支上工作的开发人员数量的增加，出现破损/阻塞的风险也会增加。最终达到了一个点，平均到修复断点时出现一个新的
虽然句子的第一部分在统计上可能是正确的，但我不同意第二部分。
CI和集成分支不能击败GIGO（如果有垃圾，那么垃圾回收）如果开发人员没有纪律，那么您最终将陷入停顿，但是集成分支测试仅应作为最后的障碍，而不是第一个障碍。 。
开发人员应使用适当的编码标准，代码审查，本地单元测试以及可能的集成前分支测试，以减少发生冲突的可能性。
我每天都在为此工作系统有成百上千的贡献者，并且令人惊讶的是它挂起。
我没有足够的数据，但是成本确实很高，另一方面，很难判断替代成本后期集成和错误。
#3 楼
另一种方法是切换到另一种非传统的CI系统，该系统能够通过在提交前确定并拒绝有问题的候选更改来防止回归，而不是检测回归并在分支的开发被阻止时等待恢复。我喜欢将这样的系统称为非阻塞CI系统。仅通过提高开发人员执行的提交前验证要求，以试图减少分支回归是不够的。实际上，这可能会导致回归率增加：更长的验证时间=>孤立地同时进行验证的更改数量更多（因此不考虑彼此）=>功能冲突和干扰的风险更高。我在扩展“提交前验证范围”应该会增加分支稳定性的神话中对此进行更详细的说明。
当然，CI工具也需要能够大规模运行。并且存在这样的工具，请参阅是否有CI工具可以保证分支机构的质量水平不退缩？
披露：我隶属于上述链接中提到的公司。
评论
您介意我重新处理您的“免责声明”吗（如果您不喜欢它，只需执行回滚）？
–Pierre.Vriens♦
17 Mar 6 '17 at 23:32
完全没有，请这样做。
–丹·科尼莱斯库（Dan Cornilescu）
17 Mar 6 '17 at 23:51
完成...与您的版本等效的IMO，符合SE要求（需要附加说明），并且使用更合适的字体（干扰较小）。如果需要，可以随时进行返工或回滚。
–Pierre.Vriens♦
17 Mar 7 '17 at 0:15
评论
对我来说，这个问题就像其他许多问题一样，使我思考“为什么这甚至是一个问题”。并不是说这是一个坏问题，而是我来自世界上的一些东西（大型机，我敢打赌，您现在知道了……）不再是一个真正的问题。这就是我们至少已经进行了十多年的工作，而IMO却像是一种魅力。否则，如何才能保持银行体系的正常运转。我只是不知道用大型机眼镜发表答案是否有意义。你觉得呢？这里的项目规模是指对正在执行的系统进行更改的大小和速度，而不一定是系统本身的大小（例如，如果项目是重写整个系统或构建它，那将很重要。从头开始）。而且上下文是单个分支，一次在功能分支上分离数天/数周/数月并不是持续集成。并不是说它不会在您的位置发生，而是说大型机上下文本身并不意味着大规模的持续集成。每天将数百次提交考虑到同一分支中。
这个问题让我还有很多其他问题-您是怎么遇到这种情况的？为什么这么多开发人员在同一个分支上工作？为什么功能分支需要自己的质量检查环境？为什么将更改推送到集成分支以破坏构建，为什么不能解决问题而不是CI扩展？他们不是在本地测试吗？在合并之前，不是从上游合并吗？
@Adrian Branchs是邪恶的-它们带来了集成地狱-冒险，缓慢，昂贵。特别是对于大型团队。分支很容易产生太多分歧，使合并变得不切实际。查找CI的优势。分支意味着孤立地工作-抵消了所有这些优势并带回了互补的劣势。是的，数十年来，分支机构已被成功用于运输软件-没有其他选择。但是现在我们有了CI。然而，许多人仍然使用分支-他们已经习惯了，甚至不再感到痛苦或选择忽略它。或遇到可扩展性问题。
CI解决了与分支完全不同的问题，并且正确使用了分支可以与CI配合使用，而不是针对它。不使用分支也不会避免集成地狱，这会使情况变得更糟：在同一分支中工作的每个人每次按下时都必须合并。