优化编译时在持续集成

也许这只是一个疯狂的人的梦想，但..优化编译时在持续集成

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

我想通过编译最后一次提交所涉及的项目，从所有其他程序集中取出所有其他程序集，以缩短开发人员（最好在Teamcity机器上）的commit-build-unittest反馈循环。一个本地nuget服务器（团队城市服务器本身版本7.0）。

现在，这将极大地砍下反馈回路（15分钟，不到一分钟，给真正单元测试）为小的提交。我知道这种部分编译的问题是跳过编译错误（不匹配的接口可能被忽视）的可能性，但是通过运行第二个（Teamcity？）构建服务器实例来运行整个enchilada可以缓解这个问题，在平行下。但立即获得第一反馈是非常重要的我。

现在我的问题：是否有任何构建系统/持续集成系统可以处理这个任务？或者我是否必须编写自己的提交感知后台服务？这会有点令人讨厌，因为我们使用FinalBuilder脚本，而且这个格式似乎不能被任何API读取（但没有深入到那个深处）。

P.S .:另外，我想只对最后一次提交发生变化的项目运行单元测试，或者至少优先考虑它们。但这是事后的想法。

来源

2011-12-27 hko

的[很慢编译在Visual Studio的时间]可能重复（HTTP ：//stackoverflow.com/questions/55517/very-slow-compile-times-on-visual-studio） – Oded 2011-12-27 15:31:57

是的，看到了，但.. 1）这是很老了，2）许多答案都没有用C＃可用， 3）少数的人，这将有助于（如一个与自定义VS加载项），不支持任何链接和被埋没所以内心深处我无法及时 – hko 2011-12-27 19:50:23

希望对一些有价值的反馈@hko我知道这似乎是一个难以想象的数字很多要浪费的点，但我会考虑在其他问题上给予奖励和/或按照答案中的每一个环节在另一边。 – 2012-01-01 22:32:05

MSBuild确实区分构建脚本目标的“构建”和“重建” - 普通构建只构建它认为自从先前构建后更改的项目。

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

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

来源

2011-12-27 15:31:01 Lucero

hrm ..听起来不错，但是：我会用它来测试补丁，因为它们失败了，它们不会被提交到“稳定”基线（使用hg）..所以我将不得不“复位”构建目录到最后从gbaseline提交..不是很难做，但我仍然有点惊讶，似乎没有一个确定的解决方案.. – hko 2011-12-27 19:43:55

大多数可用的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步中，您将知道如何将层组装成可用的应用程序。

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

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

来源

2011-12-27 15:38:00 oleksii

有用的知识，但大多数不回答这个问题，作为我的问题在于step2。 :)“您也可以通过将大型项目拆分为更小的项目并仅编译已更改的库来缩短编译时间。” - >完全可以解决我的问题，关心如何在完全自动化的构建系统中实现这一点，就像我打算建立的一样，只是基于提交？ Teamcity如何知道只有一个certian项目发生了变化？也许它可以，但在装饰上它不.. – hko 2011-12-27 19:44:55

@ hko我已经更新了答案的底部，请看看它是否有帮助。 – oleksii 2011-12-27 22:16:42

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

设置有一个Build触发，使他们第二CI项目的基础，如果你的第一个成功和有第二个项目运行测试用例第二CI项目。我用詹金斯取得了很好的成绩。

对于一个完整的构建，你可以有一个手表的根文件夹的任何更改，并揭开序幕整个解决方案的构建另一个CI项目。

设置它这样你可以在每个项目生成和代码中被选中，该项目在测试较慢的回报快速返回结果

来源

2012-04-12 19:33:34

我们使用Mercurial。不确定Teamcity是否能够自动构建特殊版本（基于回购子文件夹）进行回购更改，或者是否有任何CI系统可以。 – hko 2012-04-12 21:29:56

优化编译时在持续集成

回答

相关问题