在我们的环境中，我们有很多长期运行的功能测试，这些测试目前会占用构建代理并强制其他构建排队。由于这些代理只等待测试结果，理论上它们可以将测试交给其他机器（测试代理），然后运行排队的构建，直到测试结果可用。
对于 CI 构建（包括单元测试），这应该保持内联，因为我们希望对失败进行即时反馈，但是最好在运行功能测试所花费的时间、结果的前置时间和吞吐量之间取得更好的平衡。我们的集体建设。
据我所知，TeamCity 本身并不支持这种情况，所以我认为有几个选择：
- 启动更多代理并将它们分配到“测试”池。触发功能构建配置以在这些代理上运行（由成功的 Ci 构建触发）。虽然这似乎是最干净的，但它的扩展性不是很好，因为我们有购买许可证的前置时间，并且经常需要在替代环境中运行测试，这会暂时使所需的测试代理数量增加一倍（或更多）。
- 添加构建或构建步骤以在外部机器上启动测试，然后立即将构建标记为成功，以便可以处理排队的构建，然后当测试完成时，我们将构建标记为成功/失败。这依赖于能够更新先前构建的结果（也许是 REST API？）。将某事标记为成功然后将其更新为失败也感觉很难看，但我们总是可以选择性地监控什么，所以我们只能看到最终结果。
- 继续旋转代理，直到我们不再有构建队列。问题在于它是一个移动的目标。如果我们知道高原在哪里（或是否存在），这将是可行的方法，但我们的使用模式意味着这是不可行的。
有没有人在类似的情况下取得了成功，或者知道上述任何我没有想到的优点/缺点？