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

Question

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

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

我想简化devs的commit-build-unittest反馈循环（最好是现在在Teamcity机器上），只需编译上次提交所触及的项目，从中获取所有其他程序集。本地nuget服务器（teamcity服务器本身，版本7.0）。

现在，对于小型提交，非常会减少反馈循环（15分钟到不到一分钟，给出真正的单元测试）。

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

。

现在我的问题是：有没有可以处理这项任务的构建系统/持续集成系统？或者我是否必须编写自己的提交感知后台服务？这会有点讨厌，因为我们使用FinalBuilder Scripts，并且Format似乎没有任何API可读（但没有深入挖掘）。

P.S。：另外，我想只对最后一次提交更改的项目运行单元测试，或者至少对它们进行优先级排序。但这是事后的想法。

Answer 1

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

建议（by this book）让前4个步骤少于2-5分钟，即使对于最复杂的项目，如果超过该值，那么您的配置和方式也会出现问题你使用CI过程。

Code commit
 triggers --->

 Step 1. Automatic checkout on CI side
 Step 2. Compile code, ideally 1-2 mins  
 Step 3. Save binaries to the artifact repository
 Step 4. Unit test, ideally 1-2 mins
 Step 5. Deploy to staging
 Step 6. Automated integration testing
 Step 7. Automated acceptance testing
 ------------------------------------
 Manual testing
 Manual deploy to production

具体到第2步，你可以：

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

湾在TeamCity配置中，您可以指定是执行干净检出还是使用已有的源（可以节省第1步的时间）。检查MSBuild的目标是否设置为构建，它将仅选取自上次构建以来已更改的源文件（在步骤2中节省时间）。

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

Answer 2

使用依赖构建系统。如果您在每个项目的自己的文件夹中使用SVN，您可以为每个构建该项目的c＃项目设置一个CI项目，并通知您它是成功还是失败。

设置第二个具有构建触发器的CI项目，以便在第一个项目构建成功并且第二个项目运行测试用例时，它们可以构建第二个CI项目。我使用Jenkins取得了很好的成功。

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

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

Answer 3

MSBuild确实区分了构建脚本目标的“构建”和“重建” - 正常构建仅构建自上次构建以来它看到的更改的项目。

也就是说，从源代码控制获取源代码时，不应该清除TeamCity代理的构建目录（这样做的依赖性可能取决于SCM - 它似乎可以与Mercurial一起工作）并且只是触发构建，而不是重建。

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