改进CI构建时间(. net)

本文关键字：net 时间 CI 构建 改进 | 更新日期: 2023-09-27 18:18:44

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

<<h2> 项目细节/strong>
    4 Visual Studio解决方案
  1. ~70个项目(还在增加)
  2. 目前使用TeamCity运行2个版本:CI和完整版本。

CI每次提交时触发。

FULL -每晚运行。

我想提高两个构建的性能(特别是CI构建，因为它需要尽可能快地给出输出)。

有什么可以有效和容易地改进的一般指导方针吗?

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

方向考虑:

  • MSBuild并行
  • 覆盖CopyFilesToLocal

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

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

改进CI构建时间(. net)

尽量减少ci构建的工作量。

  • 设置工作区，隐藏任何不需要的文件夹，以尽量减少需要从源代码管理中获取的文件数量。如果有必要，重新组织你的源代码结构，这样就可以很容易地把整个文件夹的数据从构建中删除。

  • 确保ci构建使用增量获取和增量构建。

  • 只构建您需要的解决方案/项目。如果您的库不经常更改，您可以预编译它们并将二进制文件检入源代码控制系统吗?

    • 如果一个项目目前没有被积极开发，不要在ci构建中构建它。

  • 您需要为每次检入运行单元测试吗?我们只运行一个简单的ci构建代码，并使用一个单独的测试构建作为ci运行，但频率不超过每小时一次。这大大缩短了ci构建时间，但如果我们破坏了任何单元测试，仍然可以在一小时内通知我们。

  • 同样，不要构建文档、混淆、构建安装程序、用证书签名程序集等，并禁用任何将输出复制到drop文件夹的构建进程。CI构建是用来告诉你，如果你已经尽快破坏了构建，你不关心生成有用的二进制输出。

  • 总体上优化构建——将项目合并在一起，使用多线程构建，使用几个构建代理，这样ci构建就不必等待其他构建类型完成。只在夜间进行完整构建，以便在您工作时构建服务器专用于ci。保持源文件整洁(删除不使用的代码，而不是仅仅注释它，删除不使用的using/includes等)

  • 投资更好的构建服务器硬件。如果你没有顶级规格的机器，那就多放一些RAM和SSD来提高速度。确保您的构建服务器专用于ci构建，并且没有用于任何可能减慢其速度的其他操作。确保构建服务器和tfs服务器之间的网络是千兆级的。确保服务器上没有运行任何防病毒软件，或者至少它的计划扫描是在夜间运行的，并且您的构建文件夹在实时扫描排除列表中。

  • 使用tfs checkin策略来阻止开发人员在ci构建失败时检入，以便您立即停止并修复损坏。

我正在做500多个c#应用项目。并行编译项目，并将copylocal设置为false。在没有单元测试和代码覆盖的情况下，编译时间大约是37分钟。13分钟的增量构建，代码没有任何变化。如果我关闭并行编译并将copylocal设置为true，则编译时间> 1h40分钟。我有不同的配置本地构建，门控签入构建和服务器构建与部署阶段(夜间构建)。

以下是我的经历:

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

是的，MSBuild使用依赖项目的时间戳来确定项目是否需要重建。它比较输入文件(代码文件、引用程序集、临时文件等)和输出程序集的时间戳。如果更改了某些内容，则会重新编译项目。尽量减少项目之间的依赖项数量，以尽量减少重新编译。如果您的更改仅在项目的"私有"部分，则您的输出程序集将被更改，程序集时间戳将被更改，并且所有相关项目也将重新构建。你不能用这个做什么。

运行你的构建2次，诊断冗长，不改变你的代码，检查"构建目标"CoreCompile"完全"，就像我在这里描述的。您的项目文件中可能有错误，并且每次都要重新编译项目。如果你没有改变任何东西，你的构建日志不应该包含"构建目标"CoreCompile"完全"日志。

我们的构建服务器是虚拟机，而不是真正的硬件。这不是一个好主意，使用虚拟机构建服务器，但这不是我的决定。

如果您有多GB RAM，尝试使用它的一部分作为内存硬盘驱动器。你的构建应该更快:)

SSD盘对每天高I/O敏感。这对保修有影响。

希望它能帮助某人…

夜间构建不太容易受到缓慢构建时间的影响，因此您应该集中精力优化签入触发的构建。我们遇到了同样的问题，并找到了以下帮助:

  1. 只构建您更改的内容。这意味着把你的项目分成更小的项目。
  2. 在调试或发布(不同时)中构建解决方案。
  3. 保持单元测试小而快速，以便向开发人员提供快速的结果反馈。
  4. 将非关键任务仅保留到夜间构建(文档，更长的自动化测试等)。
    5. 链接所有依赖的配置，所以当你的构建成功，他们将与最近的变化构建;如果依赖配置失败，那么你马上就知道这些更改没有与现有代码集成。

我们尝试了并行MSBuild，但我不记得它是否提供了更多;可能是因为我们的代理。

此外，签出/签入时间对总时间有很大的影响，所以也许可以使用VCS，这样它只签出更改的文件会有所帮助。

  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

相关文章：