我们正在使用TeamCity作为CI服务器开发应用程序框架+“插件”。
CI - 在每次提交时触发。
FULL - 每晚跑步。
我想提高两个版本的性能（尤其是CI版本，因为它需要尽快提供输出）。
关于什么可以有效和轻松地改进，是否有任何指导方针？
构建过程只是构建一个.sln文件并运行一些单元测试。
不确定这些是否适用/将导致性能提升。
我正在寻找更多方法来改善构建时间（大约需要3-4分钟）。
答案 0 :(得分：13)
尽量减少ci构建的工作。
使用隐藏的任何不需要的文件夹设置工作区，以最大限度地减少需要从源代码管理获取的文件数。如有必要，可以重新组织您的源代码结构，这样就很容易将整个数据文件夹从构建中删除。
确保ci构建使用增量get和incremental构建。
仅构建您需要的解决方案/项目。如果您的库只是偶尔更改，您可以预先编译它们并将二进制文件检查到源代码管理中吗？如果一个项目目前没有积极开发，请不要在ci版本中构建它。
您是否需要为每次办理登机手续都进行单元测试？我们只运行一个简单的ci构建代码，单独的测试版本作为ci运行，但不会超过每小时一次。这会削减我们的ci构建时间，但如果我们打破任何单元测试，仍会在一小时内通知我们。
同样，不要构建文档，混淆，构建安装程序，使用证书对程序集进行签名等，并禁用将输出复制到drop文件夹的任何构建过程。 CI构建可以告诉您，如果您已经尽快破坏了构建，那么您并不关心生成有用的二进制输出。
一般优化构建 - 将项目合并在一起，使用多线程构建，使用多个构建代理，因此ci构建不必等待其他构建类型完成。只在一夜之间进行完整构建，因此您的构建服务器在您工作时专用于ci。保持源文件整洁（删除未使用的代码，而不是仅仅将其注释掉，删除未使用的使用/包含等）。
投资于更好的构建服务器硬件。如果您没有顶级规格的机器，请将更多RAM和SSD放入其中，以获得便宜的速度提升。确保您的构建服务器专用于ci构建，并且不会用于可能减慢其速度的任何其他内容。确保构建服务器和tfs服务器之间的网络是千兆位。确保您没有在服务器上运行任何防病毒软件，或至少其计划扫描在一夜之间运行，并且您的构建文件夹位于实时扫描排除列表中。
使用tfs检查策略以阻止开发人员检查ci版本是否失败，以便您立即停止并修复损坏。
答案 1 :(得分：8)
我正在研究500多个项目C＃应用程序。项目并行编译，copylocal设置为false。编译时间约为37分钟，没有单元测试和代码覆盖率。增量构建13分钟，代码没有任何变化。 如果我关闭并行编译并将copylocal设置为true，则编译时间> 1h40min。 我有本地构建，门控签入构建和使用部署阶段（夜间构建）的服务器构建的不同配置。
以下是我的经历：
是的，MSBuild使用dependend项目的时间戳来确定项目是否需要重建。它将输入文件（代码文件，引用的程序集，临时文件，...）时间戳与输出程序集进行比较。如果更改了某些内容，则会重新编译您的项目。尝试减少项目之间的依赖关系数，以尽量减少重新编译。如果您的更改仅在项目的“私有”部分中，则将更改输出程序集，更改程序集时间戳，并且还将重建所有相关项目。你不能做这件事。
使用诊断详细程度运行构建2次而不更改代码，并像我描述的here一样“完全”检查“构建目标”CoreCompile。您的项目文件可能有问题，每次都会重新编译项目。如果您不更改任何内容，则构建日志不应包含“构建目标”CoreCompile“完全”日志。
我们的构建服务器是虚拟机，而不是真正的硬件。将VM用于构建服务器并不是一个好主意，但这不是我的决定。
如果您有多GB RAM，请尝试将其中的一部分用作内存中的硬盘驱动器。你的构建应该快得多：）
SSD驱动器每天对高I / O敏感。它对保修有影响。
希望它可以帮助某人......;）
答案 2 :(得分：6)
每晚构建不太容易受到缓慢构建时间的影响，因此您应该专注于优化签入触发的构建。我们遇到了同样的问题并找到了以下帮助：
我们尝试了并行MSBuild，但我不记得它是否为我们提供了更多;可能是因为我们有代理人。
此外，结帐/签到时间对总时间产生了巨大影响，因此可能正在使用VCS，因此只检查更改的文件会有所帮助。
答案 3 :(得分：4)
将Copy Local设置为false当然可以节省数秒。
此外，使用RAM磁盘也是一个好主意，
减少项目编号（如果可能，合并它们）
参考文献：
http://blogs.microsoft.co.il/blogs/arik/archive/2011/05/17/speed-up-visual-studio-builds.aspx