在我们的环境中，我们有相当多的长期运行的功能测试，这些测试目前占用构建代理并强制其他构建排队 . 由于这些代理只等待测试结果，理论上它们只是将测试交给其他机器（测试代理），然后运行排队的构建，直到测试结果可用 .
对于CI构建（包括单元测试），这应该保持内联，因为我们希望对故障进行即时反馈，但是在运行功能测试所花费的时间，结果的前置时间和吞吐量之间取得更好的 balancer 会很好 . 我们的集体建设 .
据我所知，TeamCity本身并不支持这种情况，所以我认为有几个选择：
-
启动更多代理并将其分配给'Test'池 . 触发功能构建配置以在这些代理上运行（由成功的Ci构建触发） . 虽然这似乎是最干净的，但它不能很好地扩展，因为我们有一个购买许可证的前置时间，并且通常需要在备用环境中运行测试，这将暂时加倍（或更多）所需数量的测试代理 .
-
添加构建或构建步骤以在外部计算机上启动测试，然后立即将构建标记为成功，以便可以处理排队的构建，然后在测试完成时，我们将构建标记为成功/失败 . 这依赖于能够更新先前构建的结果（也许是REST API？） . 将某些东西标记为成功然后将其更新为失败也感觉很难看，但我们总是可以选择我们监控的内容，因此我们只看到最终结果 .
-
只需继续启动代理，直到我们不再有构建排队 . 这样做的问题在于它是否可行 .
有没有人在类似场景中取得过成功，或者知道上述任何我没有想过的优点/缺点？
2 回答
您对可用选项的描述似乎非常准确 . 如果要实时更新构建进度，则需要为每个正在运行的构建使一个TeamCity代理“忙” .
这里唯一的缺点似乎是代理许可证成本 . 如果测试仅在其他计算机上构建启动进程，则TeamCity代理进程本身可以在低端计算机上运行，甚至可以在单台计算机上运行多个代理程序 .
第二个场景的扩展可以是两个构建配置而不是单个构建：一个可以启动外部流程，另一个可以在外部流程完整性上触发，然后发布所有外部流程结果 . 它还可以对起始构建具有快照依赖性以维持关系 .
对于任何好奇的人，我们最终购买了更多的代理并将它们分配给测试池 . 调查证明，无法更新构建结果（我完全可以理解为什么开箱即用不支持这种丑陋） .