TeamCity测试可以异步运行

Question

在我们的环境中，我们有很多长时间运行的功能测试，这些测试目前占用构建代理并强制其他构建排队。由于这些代理只等待测试结果，理论上它们只是将测试交给其他机器（测试代理），然后运行排队的构建，直到测试结果可用。

对于CI构建（包括单元测试），这应该保持内联，因为我们想要对故障进行即时反馈，但是在运行功能测试所花费的时间，结果的前置时间和结果之间取得更好的平衡会很棒。我们集体建设的吞吐量。

据我所知，TeamCity本身并不支持这种情况，所以我认为有几个选择：

• 调出更多代理并将其分配到“测试”池。触发功能构建配置以在这些代理上运行（由成功的Ci构建触发）。虽然这似乎是最干净的，但它不能很好地扩展，因为我们有一个购买许可证的前置时间，并且通常需要在备用环境中运行测试，这将暂时加倍（或更多）所需数量的测试代理。
• 添加构建或构建步骤以在外部计算机上启动测试，然后立即将构建标记为成功，以便可以处理排队的构建，然后在测试完成时，我们将构建标记为成功/失败。这依赖于能够更新先前构建的结果（也许是REST API？）。将某些东西标记为成功然后将其更新为失败也感觉很难看，但我们总是可以选择我们监控的内容，因此我们只能看到最终结果。
• 只需继续启动代理，直到我们不再有构建排队。这个问题是它是一个移动的目标。如果我们知道高原的位置（或者它是否存在），这将是可行的方法，但我们的使用模式意味着这是不可行的。

有没有人在类似情况下取得过成功，或者知道上述任何我没有想到的优点/缺点？

Answer 1

您对可用选项的描述似乎非常准确。 如果您想要实时更新构建进度，则需要为每个正在运行的构建使一个TeamCity代理“忙碌”。

这里唯一的缺点似乎是代理牌照费用。 如果测试仅在其他计算机上构建启动进程，则TeamCity代理进程本身可以在低端计算机上运行，​​甚至可以在单台计算机上运行多个代理。

第二个场景的扩展可以是两个构建配置而不是单个构建：一个可以启动外部流程，另一个可以在外部流程完整性上触发，然后发布所有外部流程结果。它还可以对起始构建具有快照依赖性以维持关系。

Answer 2

对于任何好奇的人，我们最终购买了更多代理并将其分配到测试池。调查证明，无法更新构建结果（我完全可以理解为什么不能立即支持这种丑陋）。