如何处理TeamCity中的一个很长的过程？

Question

我们想介绍将从TeamCity驱动的新测试。构建部分本身速度相当快，但我们希望接下来的流程能够采用非常长时间（数小时到数天）。一台不同的机器将产生结果，并将分析结果。当然，我们希望在TeamCity中看到结果。

虽然我们完全期望长时间运行，但我们不希望在等待最终结果时将TC服务器占用数小时或数天。

我们看到几个基本选项：

• 估计运行时并在预定时间段进行后续测试
• 定期检查
• 在初始运行完成时手动运行另一个构建

你如何处理这样的情况？需要考虑哪些因素？你尝试过这样的事情吗？是否有效？

Answer 1

您列出的三个选项听起来很合理，但您缺少可供您使用的团队城市的重要功能。

替代方案：

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 ，您都应该有办法获得已通过一系列质量规格的成功构建。< / p>