优化持续集成中的编译时间
本文关键字：编译 时间 集成 优化 | 更新日期: 2023-09-27 18:18:49
也许这只是一个疯子的梦想，但是…
在我的公司，我们有一个很大的c# . net项目，有大约25个解决方案(很老)和大约350万。疯狂的。我面临的问题是:构建时间太慢，现在使用SSD(开发机器)需要7分钟，在使用普通硬盘的VM中需要15分钟以上(这将是我想部署的TeamCity构建系统)。我知道，构建系统应该是最快的，但这不是我能在短期内改变的。
我想缩短开发者的提交-构建-unittest反馈循环(最好现在在Teamcity机器上)，通过编译上次提交触及的项目，从例如本地nuget服务器(Teamcity服务器本身与7.0版本)获取所有其他程序集。
现在这将极大地缩短小提交的反馈循环(15分钟到不到一分钟，给定真实的单元测试)。
我知道这种部分编译的问题是跳过编译错误的可能性(不匹配的接口可能被忽视)，但是通过运行第二个(Teamcity?)并行运行整个enchilada的构建服务器实例可以减轻这个问题。但是立即得到第一个反馈对我来说非常重要。
现在我的问题是:是否有任何构建系统/持续集成系统可以处理这个任务?或者我必须编写自己的支持提交的后台服务?这就有点麻烦了，因为我们使用的是FinalBuilder脚本，而且这种格式似乎不能被任何API读取(但我没有深入研究)。
注:另外，我希望只对上次提交更改的项目运行单元测试，或者至少对它们进行优先级排序。但那是事后的想法。
大多数可用的CI引擎采用部署管道流程，这是专门为减少开发循环中的反馈时间而设计的。它的工作原理是这样的，如果任何一个步骤出错，就立即显示FAIL状态。
建议(本书)即使对于最复杂的项目，前4个步骤也要少于2-5分钟，如果超过这个时间，那么您的配置和使用CI过程的方式就有问题。
<>之前代码提交触发- - ->步骤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)，然而，这可能会带来一些潜在的bug，旧文件被保存的时间比需要的长。Teamcity还支持多个代理(免费版最多3个)，这将允许您并行运行任务。
使用依赖构建的系统。如果你在每个项目的文件夹中使用SVN，你可以为每个c#项目建立一个CI项目，它只构建该项目，并很快通知你它是成功还是失败。
设置第二个具有构建触发器的CI项目，以便在您的第一个CI项目成功的情况下构建第二个CI项目，并让第二个项目运行您的测试用例。我已经用Jenkins成功地完成了这个任务。
对于一个完整的构建，您可以有另一个CI项目来监视根文件夹中的任何更改，并启动整个解决方案的构建。
像这样设置它，您可以让每个项目构建并在代码签入时快速返回结果，而在项目的测试中返回较慢
MSBuild确实区分了构建脚本目标的"构建"answers"重建"——正常的构建只构建它认为自前一个构建以来被更改的项目。
也就是说，当从源代码控制获取源代码时，不清除TeamCity代理的构建目录应该足够了(这样做的能力可能取决于SCM -它似乎与Mercurial一起工作得很好)，只是触发构建，而不是重建。
关于单元测试，TeamCIty可以先执行失败的单元测试，但是找出哪个测试处理哪个源代码部分对我来说似乎是一项艰巨的任务，而且TeamCIty AFAIK也不支持。