在我们的环境中,有许多长时间运行的功能测试,它们目前会占用构建代理并强制其他构建排队。由于这些代理只是在等待测试结果,它们理论上可以将测试交给其他机器(测试代理),然后运行排队的构建,直到测试结果可用为止。
对于CI构建(包括单元测试),这应该保持不变,因为我们希望立即得到失败的反馈,但是更好的平衡运行功能测试所需的时间、其结果的引导时间以及我们集体构建的吞吐量将是很棒的。
就我所知,TeamCity不支持这种情况,因此我认为有几个选项:
对于CI构建(包括单元测试),这应该保持不变,因为我们希望立即得到失败的反馈,但是更好的平衡运行功能测试所需的时间、其结果的引导时间以及我们集体构建的吞吐量将是很棒的。
就我所知,TeamCity不支持这种情况,因此我认为有几个选项:
- 增加更多代理并将它们分配到“测试”池中。触发功能构建配置在这些代理上运行(由成功的Ci构建触发)。虽然这似乎是最简洁的方法,但随着需要在替代环境中运行测试的频繁出现,它无法很好地扩展,这将暂时使所需的测试代理数量增加一倍或更多。
- 添加构建或构建步骤以在外部机器上启动测试,然后立即将构建标记为成功,以便可以处理排队的构建,然后在测试完成时,我们将构建标记为成功/失败。这取决于能够更新先前构建的结果(也许是REST API?)。这也感觉很丑陋,因为我们可能会在后来将其标记为失败,但我们可以选择性地监视我们只看到最终结果。
- 一直增加代理,直到我们不再有排队的构建。问题在于这是一个移动的目标。如果我们知道高原在哪里(或者它是否存在),那么这就是要走的路,但我们的使用模式意味着这是不可行的。