在连续集成中优化编译时

Question

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

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

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

现在,对于小型提交,这将极大地减少反馈循环(15分钟到不到一分钟,给定真实的单元测试).

我知道这种部分编译的问题是跳过编译错误的可能性(不匹配的接口可能会被忽视),但是这可以通过运行第二个(Teamcity？)构建服务器实例来缓解,该实例同时运行整个enchilada.但立即获得第一反馈对我来说非常重要.

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

PS:另外,我想只为最后一次提交改变的项目运行单元测试,或者至少对它们进行优先级排序.但那是事后的想法.

Answer 1

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

也就是说，当从源代码控制获取源代码时，不必清理 TeamCity 代理的构建目录（这样做的能力可能取决于 SCM - 它似乎与 Mercurial 配合良好）并且只需触发构建即可，不是重建。

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