使用 GitHub 環境來控制部署
Proseware 自動化模型部署，但團隊不希望每次成功的工作流程執行都會立即改變生產流量。 自動化測試應該先驗證部署情況。 審查者應決定證據是否支持升遷。
表示部署階段
GitHub 環境是儲存庫中的具名部署目標，例如 staging 或 production。 工作流程作業會參考其目標環境。 GitHub 會在工作執行或存取環境機密前，評估該環境的保護規則。
環境名稱不會建立 Azure 資源。 你可以決定每個 GitHub 環境如何對應到 Azure Machine Learning 資源。 例如，暫存與生產環境可能會使用不同的工作區以加強隔離，或在同一工作區中設置獨立端點以降低管理負擔。
備註
GitHub 環境會控制部署工作。 Azure Machine Learning 環境定義了用於執行機器學習程式碼的作業系統、套件及其他相依關係。 這兩個概念是獨立的。
保護生產升級
GitHub 環境保護規則可以要求審查者、限制部署僅限於特定分支或標籤，或設定等待計時器。 對於 Proseware，只有來自 main 的執行作業才能以生產環境為目標。 必要的檢閱者會先檢查預備環境測試結果，之後才允許生產升級作業繼續進行。
這個閘門將兩個決策分隔開來。 自動檢查會判斷部署是否符合定義要求。 審查者會根據證據與操作背景，決定是否立即進行釋放。
範圍配置與存取
環境變數可以儲存不敏感的目標設定，例如 Azure Machine Learning 工作空間和端點名稱。 環境秘密僅對提及該環境的作業開放，且僅在其保護規則通過後。
使用 OIDC，你不會儲存客戶端秘密。 你仍然可以針對預備環境和生產環境使用不同的聯邦身分，然後只授予每個身分其工作所需的 Azure 權限。 這種做法可防止預備環境作業單純因與生產環境作業共用同一個存放庫，就取得生產環境的存取權。
實務的工作流程將部署與推廣區分開來。 一項作業會在沒有生產流量的情況下部署並測試新模型。 後續作業會參照受保護的 production 環境，並且僅在獲得核准後才變更流量。
Tip
在加入批准前，先確定審查者需要哪些證據。 沒有明確驗收標準的閘門會延遲部署，卻無法改善決策。
了解更多關於管理 GitHub 環境以供部署的方法。