當客戶將發行管線從傳統發行管理轉移到 YAML 時，我們遇到的第一個挑戰是大規模處理檢查。 其中兩個最常使用的檢查是 Azure 函式 和 REST API 檢查。 Azure Pipelines 中的預設體驗會導致從 Azure Pipelines 建立同步呼叫至 Azure 函式或 REST 伺服器。 除此之外，這些呼叫會經常重試，直到檢查通過為止。 此設計很簡單，適用於小型工作負載。 不過，當有大量檢查、函式或 REST 伺服器需要更多時間來回應，或有大量重試時，它不會調整。
我們將簡化異步檢查實作，也稱為 回呼模型，並變更產品中的體驗，以建議透過同步模型。 使用回呼模型，Azure 函式或 REST 伺服器可以決定在達到逾時之前隨時失敗或通過檢查，從而完全不需要重試。 此模型也允許 Azure 函式或 REST 伺服器花費盡可能多的時間來評估檢查，而不需要在 Azure Pipelines 中耗用計算資源。