大型公司如何进行持续整合？

在我的公司中，通常不做任何中间构建来检查每个功能/错误修正分支如何在dev中合并。每天只有一次构建，这总是会引发很多测试失败和构建错误。有人告诉我，为超过1000个开发人员的每次合并进行构建都是不合理的。

因此，我搜索了在拥有那么多开发人员或更多开发人员的公司（Microsoft，Facebook）中如何配置CI，却一无所获。也许内部人士可以告诉我呢？

基本上，这是一个缩放问题。您将工作分为模块，这些模块可以是不同的项目和/或产品的不同功能。

您将拥有涵盖这些模块集的团队。这些团队中的每个团队都将为其范围设置CI周期，只有在各自的周期通过之后，代码才被推送到主仓库，在此运行主CI周期。

在以下方面，主CI周期很可能与团队级别的CI周期不同：

• 团队级别的CI周期不必构建整个公司的代码，只需构建他们负责的模块和从属模块即可。如果有两个完全独立且在不同团队中的模块，则它们将不属于另一团队的CI周期。
• 团队级别的CI周期可以比主CI周期进行更详细的自动化测试。主CI周期将进行健全性检查测试和回归测试，这些测试和回归测试将根据主解决方案的大小每天或每周运行一次，因为这些测试有时可能需要超过24小时才能执行。

使用此方法必须做的是，一旦本地CI周期过去，就可以提供从本地存储库到中央存储库的自动推送，以免开发人员花费大量时间将代码推送到中央存储库。

除了@Vladimir_Stokic所说的以外，在某些团队（我的有约150个开发人员）上，我们的构建比每24小时更频繁。无论何时发生提交，我们都会启动5分钟的计时器。5分钟结束后，将合并并构建5分钟间隔内发生的所有提交。该构建通常是增量构建。我们有一个单独的构建器，该构建器针对每个发生的构建运行单元测试。构建完成后，如果在构建过程中还有其他提交（取决于更改内容，则需要1到45分钟），则将构建所有待处理的更改，等等。我们也有一个每晚（干净，完整）的版本，但是每次提交时（大致）发生的版本会很快告诉我们任何测试是否失败。