仅构建更改的项目或全部构建，在持续集成中首选哪个？

Question

我们的软件分为多个组件。

Msbuild脚本自动执行我们的构建和批处理脚本以调用它。即使有很小的变化，我们也会每天构建组件。我们希望转向持续集成，以便每当签入发生时便触发构建。

我们的msbuild脚本以这样的方式编写：它将为组件生成所有sln文件。在持续集成中，是否仅需要构建经过修改的sln？

如果我仅生成更改的项目，是否必须为每个sln编写一个msbuild？

我可以简单地在teamcity中使用现有的msbuild脚本吗？

Answer 1

我都做过，两者都有优点和缺点：

增量构建（仅更改之处）

这是MSBuild的默认行为。即使在Visual Studio中构建，它也只能构建更改的内容（除非您选择“全部重建”）。

优点

• 更快反馈循环越快越好。
• 减少构建服务器磁盘和网络上的负载，因为您不必每次都在源代码管理之外检查所有内容。这在高负载构建集群中可能很重要。

缺点

• 可能的源代码控制问题我们遇到了这样的问题，即源树的复杂重命名或重组导致检出失败。我们使用的是Subversion，因此更新失败。如果我们一直在进行干净的结帐，就不会发生这种情况（当然，干净的结帐意味着我们必须进行完整的重建）。
• 误报的机会。在某些情况下，我们没有完全清除构建代理的源文件并从源中检出新副本。有人更改了构建文件，使其在测试二进制文件之前无法正确复制它们，但是由于旧的二进制文件仍在磁盘上，因此它正在从中运行测试。该构建已被破坏，但是它正在运行旧的二进制测试，因此直到一周后我发现问题后，我们才意识到我们已经引入了错误。

全面检出和重建

优点

• 更加健壮您可以排除源代码管理更新问题和误报的可能性，因为每次您都要从头开始。这消除了以前的版本可能影响此版本的可能性。

缺点

• 慢得多这涉及到等待从源头进行完整签出，如果项目很大，则可能要花费很长时间。另外，它需要从头开始构建整个源代码树。
• 构建代理程序，磁盘和网络上的负载较高由于您正在检出并重建所有内容，因此将给构建代理程序的cpu和磁盘以及网络（以及源代码控制系统）的cpu和磁盘增加更多的负担。

第三种选择：增量检出和重建

在这种情况下，您仅从源代码管理中提取增量更改，但执行完全重建。

优点

• 比完全结帐快，实际上仅比增量构建慢一点。与进行完整检出或运行测试所需的时间相比，构建时间通常较小。
• 自从您重新构建所有源代码以来，它的功能有所增强，但误报仍会潜入。

缺点

• 可能的源代码控制故障参见我对增量构建的评论。
• 误报的机会请参阅我对增量构建的评论。

哪个最好？

这取决于您对快速反馈（速度）的需求与网络和构建代理上的资源限制之间的平衡。如果您有大量资源，并且希望快速反馈和完整重建的可靠性，则可以进行两次构建。也许在签入时执行增量构建，但每晚执行一次完整签出并重建。