部署閘道
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
蓋茨允許從外部服務自動收集健康情況訊號，然後在所有訊號成功或逾時停止部署時升級發行。 一般而言，閘道用於與事件管理、問題管理、變更管理、監視和外部核准系統有關。
使用案例
部署閘道的一些常見使用案例如下：
- 事件管理：請先確定符合特定準則，再繼續進行部署。 例如，只有在沒有優先順序為零的 Bug 時，才會發生部署。
- 尋求核准：藉由與 Microsoft Teams 或 Slack 等其他服務整合，並等候其核准，通知外部使用者，例如法律部門、稽核員或 IT 經理有關部署的資訊。
- 質量驗證：查詢管線計量，例如通過率或程式代碼涵蓋範圍，只有在它們位於預先定義的閾值內時才會部署。
- 安全性掃描：執行安全性檢查，例如成品掃描、程式代碼簽署和原則檢查。 部署閘道可能會起始掃描，並等待掃描完成，或只檢查完成。
- 與基準相關的用戶體驗：使用產品遙測，確保用戶體驗並未從基準狀態回歸。 部署前的用戶體驗計量可以做為基準。
- 變更管理：等候 ServiceNow 等系統中的變更管理程式完成，再繼續進行部署。
- 基礎結構健康情況：在部署後執行監視並驗證基礎結構是否符合合規性規則，或等候狀況良好的資源使用率和正面安全性報告。
大部分的健康情況參數會隨著時間而有所不同，定期將其狀態從狀況良好變更為狀況不良，並回到狀況良好。 為了考慮這類變化，所有網關都會定期重新評估，直到它們全部同時成功為止。 如果所有閘道在相同的間隔和設定逾時之前未成功，則發行執行和部署不會繼續。
定義階段的閘道
您可以在階段（部署前條件）或階段結束時啟用閘道（部署後條件）或兩者。 如需詳細資訊，請參閱 設定閘道 。
評估之前的延遲是在閘道評估程式的開頭延遲，可讓閘道初始化、穩定，並開始提供目前部署的準確結果。 如需詳細資訊，請參閱 網關評估流程 。
- 針對 預先部署閘道，延遲時間是針對所部署成品記錄所有 Bug 所需的時間。
- 針對 部署后閘道，延遲是已部署應用程式達到穩定作業狀態所花費的時間上限、在部署階段執行所有必要測試所花費的時間，以及部署後要記錄事件所需的時間。
預設會提供下列閘道：
- 叫用 Azure 函式：觸發 Azure 函式的執行，並確保成功完成。 如需詳細資訊，請參閱 Azure 函式工作。
- 查詢 Azure 監視器警示：觀察作用中警示的已設定 Azure 監視器警示規則。 如需詳細資訊，請參閱 Azure 監視器工作。
- 叫用 REST API：呼叫 REST API，並在傳回成功的回應時繼續。 如需詳細資訊，請參閱叫用 REST API 工作。
- 查詢工作項目：確定從查詢傳回的相符工作項目數目在閾值內。 如需詳細資料，請參閱查詢工作項目工作。
- 安全性與合規性評估：評估指定訂用帳戶和資源群組範圍內資源的 Azure 原則 合規性，並選擇性地在特定資源層級評估。 如需詳細資料，請參閱檢查 Azure 原則合規性工作。
您也可以使用 Marketplace 擴充功能來建立自己的閘道。
適用於所有閘道的評估選項包括：
- 重新評估閘門之間的時間。 閘道的後續評估之間的時間間隔。 在每個取樣間隔中，新的要求會同時傳送至每個閘道，並評估新的結果。 建議取樣間隔大於設定閘道最長的一般回應時間，以允許接收所有回應的時間進行評估。
- 逾時之後，閘道會失敗。 所有閘道的評估期間上限。 如果在相同取樣間隔期間所有閘道都成功之前達到逾時，部署將會遭到拒絕。
- 蓋茨和核准。 如果您已設定兩者，請選取閘道和核准的必要執行順序。 針對預先部署條件，預設會先提示手動核准（使用者）核准，然後在之後評估網關。 這會儲存系統，以在使用者拒絕發行時評估閘道函式。 針對部署后的條件，預設值是評估閘道，並只在所有閘道都成功時提示手動核准。 這可確保核准者擁有核准所需的所有資訊。
如需有關閘道分析的詳細資訊，請參閱 檢視核准記錄 和 監視和追蹤部署 。
網關評估流程範例
下圖說明閘道評估流程，其中，在初始穩定延遲期間和三個取樣間隔之後，會核准部署。
下圖說明閘道評估流程，在初始穩定延遲期間之後，並非所有閘道在每次取樣間隔都成功。 在此情況下，逾時期間到期之後，就會拒絕部署。
資源
相關文章
- 發行閘道和核准概觀
- 使用閘道和核准來控制部署 (機器翻譯)
- 新增階段、相依性和條件
- 發行觸發程序