改善CI构建时间(.NET)

Question

我们正在使用TeamCity作为CI服务器开发应用程序框架+"插件".

项目细节

1. 4 Visual Studio解决方案
2. ~70个项目(增加)
3. 目前使用TeamCity运行2个构建:CI和FULL构建.

CI - 在每次提交时触发.

全部 - 每晚跑步.

我想提高两个版本的性能(尤其是CI版本,因为它需要尽快提供输出).

关于可以有效和轻松改进的内容,是否有任何指导方针？

构建过程只是构建一个.sln文件并运行一些单元测试.

考虑的方向:

• MSBuild并行化
• 覆盖CopyFilesToLocal

不确定这些是否适用/将导致性能提升.

我正在寻找更多方法来改善构建时间(大约需要3-4分钟).

Answer 1

最大限度地减少ci构建的工作.

• 使用隐藏的任何不需要的文件夹设置工作区,以最大限度地减少需要从源代码管理获取的文件数.如有必要,重新组织您的源结构,以便很容易将整个数据文件夹从构建中删除.

• 确保ci构建使用增量get和incremental构建.

• 只构建您需要的解决方案/项目.如果您的库只是偶尔更改,您可以预先编译它们并将二进制文件检查到源代码管理中吗？如果当前没有积极开发项目,请不要在ci版本中构建它.

• 你需要为每次入住都进行单元测试吗？我们只运行一个简单的ci构建代码,单独的测试版本作为ci运行,但不会超过每小时一次.这削减了我们的ci构建时间,但如果我们打破任何单元测试,仍然会在一小时内通知我们.

• 同样,不要构建文档,混淆,构建安装程序,使用证书对程序集进行签名等,并禁用将输出复制到drop文件夹的任何构建过程.CI构建可以告诉您,如果您尽快破坏了构建,则不关心生成有用的二进制输出.

• 一般优化构建 - 将项目合并在一起,使用多线程构建,使用多个构建代理,因此ci构建不必等待其他构建类型完成.只在一夜之间进行完整构建,因此您的构建服务器在您工作时专用于ci.保持源文件整洁(删除未使用的代码,而不是仅将其注释掉,删除未使用的使用/包含等)

• 投资于更好地构建服务器硬件.如果您没有顶级规格的机器,请将更多RAM和SSD放入其中,以获得便宜的速度提升.确保您的构建服务器专用于ci构建,并且不会用于可能减慢其速度的任何其他内容.确保构建服务器和tfs服务器之间的网络是千兆位.确保您没有在服务器上运行任何防病毒软件,或者至少其计划扫描在一夜之间运行,并且您的构建文件夹位于实时扫描排除列表中.

• 如果ci构建失败,请使用tfs签入策略来阻止开发人员签入,以便您立即停止并修复破坏.

Answer 2

我正在研究500多个项目C#应用程序.项目并行编译,copylocal设置为false.编译时间约为37分钟,没有单元测试和代码覆盖率.增量构建13分钟,代码没有任何变化.如果我关闭并行编译并将copylocal设置为true,则编译时间> 1h40min.我有本地构建,门控签入构建和部署阶段(夜间构建)的服务器构建的不同配置.

以下是我的经历:

1. 如果要在不将CopyLocal设置为false的情况下并行构建项目,则将输出文件复制到一个目录并不是一个好主意.当多个项目引用相同的程序集时,我的程序集有时会被锁定,而MSBuild试图同时将此引用复制到输出文件夹.这个解决方案对我很有帮助.我为所有引用设置了copylocal为false,并且我的构建目录大小降低了10倍(I/O减少了10倍).我有不同的本地构建和服务器构建设置.门控签入构建和完全部署构建的不同设置.
2. 如果我启用并行构建,构建会更快,更快.如果你有强大的构建服务器,你的/ m:2构建应该比/ m:1构建快2倍.它与项目之间的依赖关系无关(如果copylocal设置为false).
3. 如果要进行快速增量构建,则应减少项目之间的依赖关系.它对完整版本没有影响(copylocal false).增量编译时间取决于构建树中已更改的项目位置.

是的,MSBuild使用dependend项目的时间戳来确定项目是否需要重建.它将输入文件(代码文件,引用的程序集,临时文件,...)时间戳与输出程序集进行比较.如果更改了某些内容,则会重新编译您的项目.尝试减少项目之间的依赖关系数,以尽量减少重新编译.如果您的更改仅在项目的"私有"部分中,则将更改输出程序集,更改程序集时间戳,并且还将重建所有相关项目.你不能做这件事.

使用诊断详细程度运行您的构建2次而不更改代码,并像我在此处描述的那样"完全"检查"构建目标"CoreCompile .您的项目文件可能有问题,每次都会重新编译项目.如果您不更改任何内容,则构建日志不应包含"构建目标"CoreCompile"完全"日志.

我们的构建服务器是虚拟机,而不是真正的硬件.将VM用于构建服务器并不是一个好主意,但这不是我的决定.

如果您有多GB RAM,请尝试将其中的一部分用作内存中的硬盘驱动器.你的构建应该快得多:)

SSD驱动器每天对高I/O敏感.它对保修有影响.

希望它可以帮助某人...;)

Answer 3

每晚构建不太容易受到缓慢构建时间的影响,因此您应该专注于优化签入触发的构建.我们遇到了同样的问题,发现以下内容可以提供帮助:

1. 只构建你已经改变的东西.这意味着将您的项目拆分为较小的项目.
2. 在Debug或Release(不是两者)中构建解决方案.让夜间建立两者.
3. 保持单元测试小而快,以便向开发人员快速反馈结果.
4. 将非关键任务仅保留在夜间构建中(文档,更长的自动化测试等).
5. 链接所有依赖配置,因此当您的构建成功时,它们将构建最近的更改; 如果依赖配置失败,那么您立即知道更改未与现有代码集成.

我们尝试了并行MSBuild,但我不记得它是否为我们提供了更多; 可能是因为我们有代理人.

此外,结账/签到时间对总时间产生了巨大影响,因此可能正在使用VCS,因此只检查更改的文件会有所帮助.

Answer 4

1. 将 Copy Local 设置为 false 当然可以节省大量时间。

2. 此外，使用RAM盘也是一个好主意，

3. 减少项目数量（如果可能的话合并它们）

参考：

http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx

http://www.simple-talk.com/content/print.aspx?article=1237