如何处理TeamCity中的漫长过程？

Question

我们想介绍一些将从TeamCity驱动的新测试。构建部分本身速度相当快，但我们期望随后的过程需要很长时间（几小时到几天）。不同的机器将产生结果，并分析结果。当然，我们希望在TeamCity的最后看到结果。

虽然我们完全期望长时间运行，但我们不想让TC服务器在等待最终结果时保持数小时或数天的运行。

我们看到几个基本选项：

• 估计的运行时间，并在预定的时间周期
• 保持定期另一个构建手动检查
• 运行时的初始运行运行后续测试是完整的

你如何处理这样的情况？需要考虑什么样的考虑因素？你有没有尝试过这样的事情，并做到了（或没有）？

Answer 1

您列出的三个选项听起来很合理，但您错过了可供您使用的teamcity的重要功能。

一种替代方案：

1. 设置将运行ONLY了很长的过程构建。我们称之为Long_Build
2. 有第二次构建，分析取决于Long_Build的成功。免得叫这个Analysis_Build
3. 设置一个能够运行Long_Build的代理，Teamcity将只在该代理上运行构建。
4. 让您的QA构建，或主构建或任何构建成功IFF（当且仅当）Analysis_Build检出。该构建特别是一个信息收集构建，可能会检查您的其他所有测试以及您的QA部署依赖的所有内容，以便调用足以部署的变更集或一组变更集。

我的建议是不要手动运行构建。无论您用什么标准手动运行构建，都可以编写脚本并自动运行。通过这种方式，您更接近持续集成过程，您可以保证质量。另外，如果您还没有这样做，请确保您使用成功构建标记源代码管理。不管是你的Long_Build,Analysis_Build或QA build你应该有办法获得已经通过一系列质量规格的成功构建。