デプロイ ゲート

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

ゲートを使うと、外部サービスから正常性シグナルを自動的に収集し、すべてのシグナルが成功したときにリリースを促進したり、タイムアウトでデプロイを停止したりすることができます。 通常、ゲートは、インシデント管理、問題管理、変更管理、監視、外部承認システムなどと関連して使われます。

ユース ケース

デプロイ ゲートには次のような一般的なユース ケースがあります。

• インシデント管理: デプロイに進む前に、特定の条件が満たされていることを確認します。 たとえば、優先度が 0 のバグが存在しない場合にのみデプロイが行われるようにします。
• 承認を求める: Microsoft Teams や Slack などの他のサービスと統合し、承認を待つことで、法的部門、監査者、IT マネージャーなどの外部ユーザーにデプロイについて通知します。
• 品質の検証: 合格率やコード カバレッジなどのパイプライン メトリックを照会して、それらが事前定義済みのしきい値内にある場合にのみデプロイします。
• セキュリティ スキャン: 成果物のスキャン、コード署名、ポリシー チェックなどのセキュリティ チェックを実行します。 デプロイ ゲートがスキャンを開始してその完了を待機する場合や、ただ完了をチェックするだけの場合があります。
• ベースラインを基準としたユーザー エクスペリエンス: 製品テレメトリを使って、ユーザー エクスペリエンスがベースラインの状態から低下しないようにします。 デプロイ前のユーザー エクスペリエンス メトリックをベースラインとして使用できます。
• 変更管理: ServiceNow などのシステムの変更管理手順が完了するまで待ってから、デプロイに進みます。
• インフラストラクチャの正常性: デプロイ後にコンプライアンス規則に照らして、インフラストラクチャの監視を実行し、検証します。または、正常なリソースの使用と肯定的なセキュリティ レポートを待ちます。

正常性パラメーターのほとんどは時間の経過と共に変化します。その状態は定期的に正常から異常に変わり、また正常に戻ります。 このような変化に対処するために、すべてのゲートが同時に成功するまで、すべてのゲートが定期的に再評価されます。 すべてのゲートが同じ間隔内で、構成したタイムアウトの前に成功しないと、リリースの実行とデプロイは行われません。

ステージのゲートを定義する

ゲートは、ステージの開始時 (デプロイ前の条件) またはステージの最後 (デプロイ後の条件)、またはその両方で有効にすることができます。 詳しくは、「ゲートを設定する」を参照してください。

評価前の遅延は、ゲート評価プロセスの開始時の遅延時間です。これにより、ゲートは現在のデプロイに関して初期化、安定化、および正確な結果の提供を開始できます。 詳しくは、ゲートの評価フローに関する記事を参照してください。

• デプロイ前ゲートの場合、遅延は、デプロイされる成果物に対してすべてのバグをログするために必要な時間になります。
• デプロイ後ゲートの場合、遅延は、デプロイされたアプリが安定した運用状態に達するまでの最長時間、デプロイされたステージで必要なすべてのテストの実行にかかる時間、デプロイ後にインシデントをログするのにかかる時間になります。

既定で、次のゲートを使用できます。

• [Azure 関数の呼び出し]: Azure 関数の実行をトリガーし、正常に完了するようにします。 詳細については、「Azure 関数タスク」を参照してください。
• [Azure Monitor アラートのクエリ]: 構成した Azure Monitor アラート規則を観察して、アクティブなアラートを確認します。 詳細については、「Azure Monitor タスク」を参照してください。
• [REST API の呼び出し]: REST API を呼び出し、成功の応答が返された場合は続行します。 詳細については、「REST API タスクの呼び出し」を参照してください。
• [作業項目のクエリ]: クエリから返された一致する作業項目の数がしきい値以内であることを確認します。 詳細については、「作業項目のクエリ タスク」を参照してください。
• [Security and compliance assessment] (セキュリティとコンプライアンスの評価): 指定したサブスクリプションとリソース グループのスコープ内で、また必要に応じて特定のリソース レベルで、リソースに対する Azure Policy コンプライアンスを評価します。 詳細については、「Azure Policy コンプライアンス タスクを確認する」を参照してください。

Marketplace 拡張機能を使用して独自のゲートを作成することもできます。

すべてのゲートに適用される評価オプションは次のとおりです。

• ゲートの再評価までの時間。 ゲートの連続した評価の間の時間間隔です。 サンプリング間隔ごとに、新しい要求が各ゲートに同時に送信され、新しい結果が評価されます。 サンプリング間隔は、構成したゲートの最も長い標準応答時間よりも長くして、すべての応答を受信して評価する時間を与えるようにすることをお勧めします。
• ゲートが失敗するまでのタイムアウト。 すべてのゲートの最長評価期間です。 同じサンプリング間隔ですべてのゲートが成功する前にタイムアウトに達すると、デプロイは拒否されます。
• ゲートと承認。 ゲートと承認の両方を構成している場合は、それらに必要な実行順序を選択します。 デプロイ前の条件の場合、既定では、最初に手動 (ユーザー) の承認を求め、その後ゲートを評価します。 これにより、リリースがユーザーによって拒否された場合は、システムでゲート機能を評価する必要がなくなります。 デプロイ後の条件の場合、既定では、ゲートを評価し、すべてのゲートが成功した場合にのみ手動の承認を求めます。 これにより、承認者は承認に必要なすべての情報を確認できます。

ゲートの分析について詳しくは、承認ログの表示に関する記事と「デプロイの監視と追跡」を参照してください。

ゲート評価フローの例

次の図は、ゲート評価のフローを示しています。ここでは、最初の安定化遅延期間と 3 つのサンプリング間隔の後に、デプロイが承認されます。

次の図は、ゲート評価のフローを示しています。ここでは、最初の安定化遅延期間の後、各サンプリング間隔ですべてのゲートが成功していません。 この場合、タイムアウト期間が過ぎると、デプロイは拒否されます。

リソース

• カスタム ゲートを作成する
• リリース ゲートとしての Twitter センチメント
• リリース ゲートとしての GitHub イシュー

関連記事

• リリース ゲートと承認の概要
• ゲートと承認を使用してデプロイを制御する
• ステージ、依存関係、条件の追加
• リリース トリガー