TeamCity測試可以異步運行

Question

在我們的環境中，我們有很多長時間運行的功能測試，它們將構建代理和強制其他構建排隊。由於這些代理只等待測試結果，因此理論上可以將測試交給其他機器（測試代理），然後運行排隊構建，直到測試結果可用。因爲我們希望即時反饋故障，但對於CI構建（包括單元測試），這應該保持內聯，但在運行功能測試所需的時間，結果的前置時間，和我們集體建設的吞吐量。

據我所知，TeamCity的本身不支持此方案，所以我想有幾個選項：

• 旋轉起來更多的代理商，並將它們分配到一個「測試」池。觸發功能構建配置在這些代理上運行（由成功的Ci構建觸發）。雖然這看起來最清潔，但它不能很好地擴展，因爲我們然後有購買許可證的前置時間，並且通常需要在備用環境中運行測試，這些環境會臨時增加（或更多）所需數量的測試代理。
• 添加構建或構建步驟以在外部機器上啓動測試，然後立即將構建標記爲成功，以便可以處理排隊的構建，然後在測試完成時將構建標記爲成功/失敗。這依賴於能夠更新以前版本的結果（REST API或許？）。將事情標記爲成功並且稍後將其更新爲失敗也感覺很難，但是我們可以始終對我們監控的事情有選擇性，所以我們只能看到最終結果。
• 只要繼續旋轉代理，直到我們不再有構建排隊。問題在於它是一個移動的目標。如果我們知道高原在哪裏（或者它是否存在），這就是要走的路，但是我們的使用模式意味着這是不可行的。

有沒有人有類似的情況下成功，或知道以上任何我沒有想到的利弊/？

Answer 1

對於任何人都好奇，我們最終購買了更多的代理商，並將其分配到測試池。調查證明，不可能更新構建結果（我完全可以理解這個醜陋爲什麼不支持開箱即用）。

Answer 2

您對可用選項的描述似乎相當準確。 如果您想要更新生成進度，您需要爲每個正在運行的版本創建一個「繁忙」TeamCity代理。

這裏唯一的缺點似乎是代理商許可成本。 如果測試僅在其他機器上建立啓動進程，則TeamCity代理進程本身可以在低端機器上運行，甚至可以在單臺計算機上運行多個代理。

對第二種情況的擴展可以是兩種構建配置而不是單一配置：一種可以啓動外部過程，另一種可以觸發外部過程完整性，然後發佈所有外部過程結果。它也可以在啓動構建上具有快照依賴性以維護關係。