在持续集成中优化编译时间答案

【问题标题】：optimize compiletime in Continuous Integration在持续集成中优化编译时间
【发布时间】：2012-01-28 14:18:33
【问题描述】：

也许这只是一个疯子的梦想，但是..

在我的公司，我们有一个大型 C# .NET 项目，有大约 25 个解决方案（非常旧）和大约 3.5 个 mio。地点我面临的问题是：构建时间太慢，现在使用 SSD（开发机器）需要 7 分钟，使用普通硬盘驱动器的 VM 需要 15 分钟以上（这将是我想要部署的 TeamCity 构建系统）。我知道，构建系统应该是最快的，但短期内我无法改变。

我想缩短开发人员的提交-构建-单元测试反馈循环（最好现在在 Teamcity 机器上），只需编译上次提交所触及的项目，从例如获取所有其他程序集。本地 nuget 服务器（teamcity 服务器本身，版本 7.0）。

现在这将大大减少小提交的反馈循环（15 分钟到不到一分钟，考虑到 真正的单元测试）。

我知道这种部分编译的问题是可能会跳过编译错误（不匹配的接口可能会被忽视），但可以通过运行第二个（Teamcity？）构建服务器实例来缓解这种情况，该实例运行整个 enchilada，在平行线。但立即获得第一反馈对我来说非常很重要。

现在我的问题是：是否有任何构建系统/持续集成系统可以处理此任务？还是我必须编写自己的提交感知后台服务？这有点令人讨厌，因为我们使用 FinalBuilder 脚本，并且任何 API 似乎都无法读取该格式（但没有深入挖掘）。

P.S.：另外，我只想为上次提交更改的项目运行单元测试，或者至少优先考虑它们。但这是事后的想法。

【问题讨论】：

Very slow compile times on Visual Studio的可能重复
是的，看到了，但是.. 1) 它很旧，2) 许多答案不适用于 C#，3) 少数有帮助的答案（比如带有自定义 VS Addin 的答案）不支持任何链接，并且被埋得太深，我无法及时获得一些有价值的反馈
@hko 我知道这似乎是一个难以想象的点数浪费，但我会考虑在另一个问题上悬赏和/或关注另一边答案中的每个链接。
@RubenBartelink 有 78 个代表.. 是的，这有点苛刻 ;) 会考虑它；
@hko 不敢相信我建议过：D 请不要真的这样做！

标签： c# build compilation teamcity

【解决方案1】：

大多数可用的 CI 引擎采用 部署管道 流程，该流程专门用于减少开发循环中的反馈时间。它的工作原理是这样的，如果任何步骤出错，就会立即显示 FAIL 状态。

建议 (by this book) 即使对于最复杂的项目，前 4 个步骤也应少于 2-5 分钟，如果超过此时间，则说明您的配置和使用方式存在问题CI 流程。

代码提交触发---> Step 1. CI 端自动结账步骤 2. 编译代码，最好是 1-2 分钟步骤 3. 将二进制文件保存到工件存储库步骤 4. 单元测试，最好是 1-2 分钟步骤 5. 部署到登台步骤 6. 自动化集成测试步骤 7. 自动化验收测试 ---------------------------------- 手动测试手动部署到生产环境

具体到第 2 步，您可以：

一个。将大型解决方案拆分为单独的层。每个层都有自己的 Visual Studio 解决方案，并且只有与该层相关的项目，从某种意义上说，您执行初始庞大解决方案的分散化。在第 5 步中，您将了解如何将层组装成可用的应用程序。

b.在 TeamCity 配置中，您可以指定是执行干净签出还是使用已经可用的源（可以节省第 1 步的时间）。检查 MSBuild 的目标是否设置为 Build，这将只获取自上次构建以来已更改的源文件（节省第 2 步的时间）。

根据个人经验，选项 a) 是最好的选项，但如果需要，您也可以同时使用 a) 和 b)，但这可能会带来一些潜在的错误，即旧文件的保存时间超过所需时间。 Teamcity 还支持多个代理（免费版最多 3 个），这将允许您并行运行任务。

【讨论】：

很高兴知道，但大部分都没有回答问题，因为我的问题在于步骤 2。 :) “您还可以通过将大型项目拆分为较小的项目并仅编译那些已更改的库来减少编译时间。” -> 这完全可以解决我的问题，想解释一下这在我打算设置的完全自动化的构建系统中是如何实现的，只是基于提交？ Teamcity 怎么会知道只有某个项目发生了变化？也许它可以，但显然它没有..
@hko 我已经更新了答案的底部，请看看它是否有帮助。

【解决方案2】：

使用依赖构建的系统。如果您将 SVN 与各自文件夹中的每个项目一起使用，您可以为每个 c# 项目设置一个 CI 项目，该项目只构建该项目并很快通知您它是成功还是失败。

设置具有构建触发器的第二个 CI 项目，以便在您的第一个项目成功时构建第二个 CI 项目并让第二个项目运行您的测试用例。我已经使用 Jenkins 成功地做到了这一点。

对于完整的构建，您可以拥有另一个 CI 项目来监视根文件夹的任何更改并启动整个解决方案的构建。

这样设置，您可以让每个项目在签入代码时快速构建并返回结果，并且项目测试的返回速度较慢

【讨论】：

我们使用 Mercurial。不确定 Teamcity 是否能够在 repo 更改时自动构建特殊构建（基于 repo 子文件夹），或者是否任何 CI 系统都可以。

【解决方案3】：

MSBuild 确实区分了构建脚本目标的“构建”和“重建” - 正常构建仅构建它认为自先前构建以来发生更改的项目。

也就是说，在从源代码控制获取源代码时，不清除 TeamCity 代理的构建目录就足够了（这样做的能力可能取决于 SCM - 它似乎可以与 Mercurial 一起正常工作）并触发构建，而不是重建。

关于单元测试，TeamCIty 可以先执行失败的测试，但找出哪些测试解决了哪些源代码部分对我来说似乎是一项艰巨的任务，而且 TeamCity AFAIK 不支持。

【讨论】：

hrm.. 听起来不错，但是：我会用它来测试补丁，因为它们失败了，它们不会被提交到“稳定”基线（使用 hg）.. 所以我必须“将构建目录重置为来自 gbaseline 的最后一次提交 .. 不是很难做到，但我仍然有点惊讶，似乎没有一个既定的解决方案..