我目前正在尝试减少在TeamCity中编译和单元测试项目所需的时间。
目前我的项目需要5到8分钟才能构建。
它的作用是:
一旦完成,单元测试就会启动,运行大约需要2分钟。
它的作用是:
现在,运行单元测试只需要5秒....所以清理和编译步骤大约需要2分钟....创建安装程序步骤大约需要3到6分钟。
我的第一个问题是:有没有办法配置团队城市,以便在运行单元测试时不必再执行清理和编译步骤。我相信我们这样做的主要原因是因为项目构建和单元测试可以由不同的构建代理运行。
我的第二个问题是:项目构建需要5到8分钟的合理时间吗?有没有办法优化解决方案中项目的编译以及安装程序的创建?
请告诉我是否有任何我可以提供的其他详细信息可以帮助您指出正确的方向,无论是优化构建还是只是保留原样。
更新以回答一些questions from Nate:
当您在TeamCity外部运行构建时,它是否在单元测试之前再次进行清理/编译?不,因为当您在自己的计算机上运行它时,您可以指定要运行的构建脚本的哪些部分。我们有清理,编译,单元测试等部分,在团队城市中以不同的方式指定项目构建与单元测试运行。
如果是这样,你可以在测试之前让构建不这样做吗?我们目前不这样做的原因是因为当使用不同的构建代理时,单元测试所需的文件将不可用,因此会失败。
你用什么来建立你的项目?我们使用Nant构建我们的项目,wix用于安装程序,NUnit和NCover用于单元测试和覆盖率报告。
您使用的是哪种源控制系统?颠覆
答案 0 :(得分:3)
关于#1:当你在TeamCity之外运行构建时,它是否在单元测试之前再次进行清理/编译?如果是这样,你可以在测试之前使构建不这样做吗?
你用什么来建立你的项目?你使用什么源控制系统?
另一个选择考虑是具有多个构建配置。在我的工作中,我们有几种配置。每次提交后运行的一个。它做了一个干净/编译和一些快速测试。然后我们有一个nightly配置,它执行clean / compile和所有测试。你能做那样的事吗?
答案 1 :(得分:1)
根据经验,您应该将提交时触发的构建保持为尽可能短,因此您应该尝试将构建配置重构为细长的提交构建,并且每小时左右运行一次当前配置。