团队城市的测试是否可以异步运行？

Question

3

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

对于CI构建（包括单元测试），这应该保持不变，因为我们希望立即得到失败的反馈，但是更好的平衡运行功能测试所需的时间、其结果的引导时间以及我们集体构建的吞吐量将是很棒的。

就我所知，TeamCity不支持这种情况，因此我认为有几个选项：

增加更多代理并将它们分配到“测试”池中。触发功能构建配置在这些代理上运行（由成功的Ci构建触发）。虽然这似乎是最简洁的方法，但随着需要在替代环境中运行测试的频繁出现，它无法很好地扩展，这将暂时使所需的测试代理数量增加一倍或更多。
添加构建或构建步骤以在外部机器上启动测试，然后立即将构建标记为成功，以便可以处理排队的构建，然后在测试完成时，我们将构建标记为成功/失败。这取决于能够更新先前构建的结果（也许是REST API？）。这也感觉很丑陋，因为我们可能会在后来将其标记为失败，但我们可以选择性地监视我们只看到最终结果。
一直增加代理，直到我们不再有排队的构建。问题在于这是一个移动的目标。如果我们知道高原在哪里（或者它是否存在），那么这就是要走的路，但我们的使用模式意味着这是不可行的。

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

- JRoughan

2个回答

1

你对可用选项的描述似乎相当准确。如果您想要实时更新构建进度，您需要为每个正在运行的构建使用一个TeamCity代理程序。

唯一的缺点在于代理许可证成本。如果测试构建只是在其他机器上启动进程，则TeamCity代理进程本身可以在低端机器上运行，甚至可以在单台计算机上运行多个代理。

第二种情况的扩展可以是两个构建配置而不是单个构建配置：一个将启动外部进程，另一个可以在外部进程完成后触发，并将所有外部进程结果发布为自己的结果。它还可以在起始构建上具有快照依赖关系以维护关系。

- Yaegor

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- JRoughan · Accepted Answer

如果有人感到好奇，我们最终购买了更多的代理并将它们分配到一个测试池中。调查证明，无法更新构建结果（我完全理解为什么这种丑陋的操作不被默认支持）。