デプロイ ゲート

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

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

ユース ケース

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

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

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

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

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

評価前の遅延は、ゲート評価プロセスの開始時の時間遅延であり、ゲートを初期化し、安定させ、現在のデプロイに対して正確な結果を提供し始めます。 詳細については、 ゲート評価フロー を参照してください。

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

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

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

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

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

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

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

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

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

ゲート評価フローの例

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

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

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

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

リソース