GitHub環境でデプロイを制御する
Proseware はモデルのデプロイを自動化しますが、成功したすべてのワークフロー実行で運用環境のトラフィックをすぐに変更することを望んでいません。 自動テストでは、最初にデプロイを確認する必要があります。 その後、校閲者は、証拠が昇格をサポートするかどうかを決定する必要があります。
配置ステージを表す
GitHub環境は、stagingやproductionなど、リポジトリ内の名前付きデプロイ ターゲットです。 ワークフロー ジョブは、対象となる環境を参照します。 GitHubは、ジョブが実行される前、または環境シークレットにアクセスする前にその環境の保護規則を評価します。
環境名では、Azure リソースは作成されません。 各GitHub環境をAzure Machine Learning リソースにマップする方法を決定します。 たとえば、ステージングと運用では、分離を強化するために個別のワークスペースを使用したり、管理オーバーヘッドを減らしたりするために 1 つのワークスペースに個別のエンドポイントを使用したりする場合があります。
Note
GitHub環境は、デプロイ ジョブを制御します。 Azure Machine Learning環境では、機械学習コードの実行に使用されるオペレーティング システム、パッケージ、およびその他の依存関係を定義します。 2 つの概念は独立しています。
運用環境の昇格を保護する
GitHub環境保護規則では、レビュー担当者を要求したり、選択したブランチまたはタグにデプロイを制限したり、待機タイマーを追加したりできます。 Proseware では、main からの実行のみが本番環境をターゲットにできます。 必須レビュアーは、本番環境への昇格ジョブの続行を許可する前に、ステージングテストの結果を確認します。
このゲートは、2 つの決定を分離します。 自動チェックによって、デプロイが定義された要件を満たしているかどうかが決まります。 レビュー担当者は、証拠と運用コンテキストを考慮して、リリースを今すぐ続行するかどうかを決定します。
スコープの構成とアクセス
環境変数には、Azure Machine Learning ワークスペースやエンドポイントの名前など、機密ではない対象設定を格納できます。 環境シークレットは、その環境を参照するジョブでのみ使用でき、その保護規則に合格した後にのみ使用できます。
OIDC では、クライアント シークレットは格納されません。 ステージングと運用に異なるフェデレーション ID を引き続き使用し、各 ID にジョブに必要なAzureアクセス許可のみを付与できます。 この方法では、両方のジョブが同じリポジトリを使用するため、ステージング ジョブが運用環境にアクセスできないようにします。
実際のワークフローでは、展開と昇格を分離します。 1 つのジョブで、運用トラフィックなしで新しいモデルをデプロイしてテストします。 後のジョブは、保護された production 環境を参照し、承認後にのみトラフィックを変更します。
Tip
承認を追加する前に、レビュー担当者が必要とする証拠を特定します。 明確な受け入れ基準のないゲートは、決定を改善することなくデプロイを遅らせています。
デプロイ用のGitHub環境の管理の詳細について説明します。