デプロイ ゲート

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

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

ユース ケース

デプロイ ゲートの一般的なユース ケースは次のとおりです。

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

ほとんどの正常性パラメーターは時間の経過に伴って変化し、定期的に状態が正常から異常に変わり、正常に戻ります。 このようなバリエーションを考慮するために、すべてのゲートが同時に成功するまで、すべてのゲートが定期的に再評価されます。 すべてのゲートが同じ間隔で成功せず、構成されたタイムアウトの前に成功しない場合、リリースの実行とデプロイは続行されません。

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

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

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

ゲートでの評価機能の前の遅延を示すスクリーンショット。

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

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

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

既定のゲートを示すスクリーンショット。

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

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

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

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

ゲート評価フローの例

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

ゲート評価フロー図を示すスクリーンショット。

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

ゲートの承認と失敗の例を示すスクリーンショット。

リソース