1

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

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

我们的 msbuild 脚本是这样编写的，它将为组件构建所有 sln 文件。在持续集成中，我是否只需要构建修改后的 sln？

如果我只构建更改的项目，我是否必须为每个 sln 编写一个 msbuild？

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

4

3 回答 3

5

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

增量构建（仅更改的内容）

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

优点

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

缺点

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

完整结帐和重建

优点

  • 更强大您排除了源代码控制更新问题和误报的可能性，因为您每次都从一个干净的状态开始。这消除了先前构建可能影响此构建的可能性。

缺点

  • 慢得多这涉及等待从源代码进行完整的结帐，如果项目很大，这可能需要很长时间。此外，它需要从头开始构建整个源代码树。
  • 构建代理、磁盘和网络上的更高负载因为您要检查和重建所有内容，所以您将对构建代理的 CPU 和磁盘以及网络（以及您的源代码控制系统）产生更多的负担。

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

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

优点

  • 比完全结帐更快，实际上只比增量构建慢一点。与进行完整检出或运行测试所需的时间相比，构建时间通常很短。
  • 由于您重建了所有源，因此更加强大，但误报仍然可以潜入。

缺点

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

哪个最好？

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

于 2012-11-05T04:49:28.573 回答
1

两者，有点。我们每天进行计划的完整构建，并在白天进行增量构建（门控签入）。

一切都取决于您的构建实际上有多大和多复杂，但是如果您要选择其中一个，则应该朝着完整的方向发展。

于 2012-11-02T14:54:09.213 回答
0

无论您的构建粒度是什么，我的偏好都是对整个组件进行完整、干净的构建。如果 CI 循环的构建时间过长，请考虑将该组件分解为依赖于彼此二进制文件的较小部分。在这种情况下，您将构建更改的内容以及依赖于更改的组件的任何其他组件。在 .Net 世界中，我听说 Nuget 在管理这些二进制依赖项方面越来越受欢迎。

在我的CI 疼痛缓解系列的练习 2 中，我更多地谈论了这个策略。

于 2012-11-02T14:50:11.723 回答