承認とチェックを定義する

Azure DevOps Services

パイプラインは、ステージで構成されます。 パイプライン作成者は、ステージで条件を定義することで、ステージを実行するかどうかを制御できます。 ステージを実行するかどうかと、そのタイミングを制御するもう 1 つの方法は、承認とチェックを使用することです。

承認やその他のチェックは、yaml ファイルでは定義されません。 パイプラインの yaml ファイルを変更しているユーザーは、ステージの開始前に実行されるチェックを変更できません。 リソースの管理者は、Azure Pipelines の Web インターフェイスを使用してチェックを管理します。

パイプラインは、環境、サービス接続、エージェント プール、変数グループ、セキュリティで保護されたファイルなどのリソースに依存します。 チェックを使用すると、"リソースの所有者" は、任意のパイプラインのステージでリソースを消費できるかどうかとそのタイミングを制御できます。 リソースの所有者は、そのリソースを消費するステージを開始する前に満たす必要があるチェックを定義できます。 例えば、環境に対する手動承認チェックは、指定されたユーザーがデプロイされる変更をレビューした後にのみ、その環境へのデプロイが行われることを保証します。

ステージは多数のジョブで構成でき、各ジョブでは複数のリソースが消費される場合があります。 ステージの実行を開始する前に、そのステージで使用されるすべてのリソースのチェックをすべて満たす必要があります。 Azure Pipelines は、各ステージの前にパイプラインの実行を一時停止し、保留中のすべてのチェックが完了するまで待機します。

承認とチェックには5つのカテゴリがあり、各カテゴリ内で作成された順序で実行されます。 チェックは、各チェックで指定された再試行のサイクル間隔に基づいて再評価されます。 タイムアウトが指定されるまですべてのチェックが完了しない場合、そのステージは実行されません。 いずれかのチェックが最終的に失敗した場合 (たとえば、いずれかのリソースで承認を拒否した場合など)、そのステージは実行されません。

静的チェックが最初に実行され、次に事前チェックの承認が実行されます。 次のカテゴリが順番に表示されます。

1. 静的チェック：分岐制御、必要なテンプレートと評価アーティファクト
2. 事前チェック承認
3. ダイナミックチェック：承認、Azure関数の呼び出し、REST APIの呼び出し、営業時間、Azure Monitorアラートの照会
4. チェック後の承認
5. 排他ロック

「承認とチェック」タブにも実行順序が表示されます。

承認

承認チェックを使用することにより、ステージを実行するタイミングを手動で制御できます。 このチェックは一般的に、運用環境へのデプロイを制御するために使用されます。

1. Azure DevOps 組織にサインインしてから、プロジェクトに移動します。

2. Pipelines>環境を選択し、続いてお使いの環境を選択します。

3. [承認とチェック] タブを選択して、+記号を選択し、新しいチェックを追加します。

   

4. [承認] を選択し、 [次へ] を選択します。

5. ユーザーまたはグループを、指定された 承認者として追加し、必要に応じて、承認者に指示を提供します。 承認者による独自の実行を承認することを許可または制限するかどうかを指定して、目的の タイムアウトを指定します。 指定したタイムアウト内に承認が完了しない場合、ステージは [スキップ] としてマークされます。

6. 終わったら [作成] を選択します。

   

7. 承認チェックがトリガーされると、次の例に示すように、プロンプト ウィンドウがユーザー インターフェイスに表示されます。 このウィンドウには、承認者が実行を拒否または承認できるオプションと、それに付随する指示が表示されます。

   

承認を確認できるユーザーのリストは、承認とチェックの実行が開始された時点で固定されます。 つまり、チェックの実行開始後に行われた承認チェックのユーザーおよびグループのリストへの変更はピックアップされません。

ブランチ コントロール

ブランチ コントロール チェックを使用すると、パイプラインにリンクされているすべてのリソースが許可されたブランチからビルドされ、そのブランチで保護が有効になっていることを確認できます。 このチェックは、リリースの準備とデプロイの品質を制御するのに役立ちます。 パイプラインに複数のリソースがリンクされている場合は、すべてのリソースのソースが検証されます。 別のパイプラインをリンクしている場合は、デプロイされている特定の実行のブランチが保護用に検証されます。

ブランチ コントロール チェックを定義する方法は次のとおりです。

1. Azure DevOps プロジェクトで、保護する必要のあるリソース (たとえば、環境など) に移動します。

2. リソースの [承認とチェック] に移動します。

3. [ブランチ コントロール]チェックを選択し、許可されたブランチのコンマ区切りの一覧を指定します。 ブランチで保護の有効を義務付けることができます。 また、ブランチの 1 つの保護ステータスが不明な場合のチェックの動作を定義することもできます。 少なくとも 1 つのポリシー (リポジトリ レベルで適用されたポリシーを含む) が適用されている場合、ブランチは保護されていると見なされます。

   

実行時に、チェックによって、許可されたリストに対して、実行内のすべてのリンクされたリソースのブランチが検証されます。 いずれかのブランチが条件と一致しない場合、チェックは失敗し、ステージは失敗とマークされます。

[営業時間]

環境へのすべてのデプロイを特定の時間枠でのみ行う場合は、ビジネス時間チェックが最適なソリューションです。 パイプラインを実行すると、リソースを使用するステージの実行はビジネス時間まで待機されます。 複数の実行が同時に実行されている場合は、各実行は個別に検証されます。 ビジネス時間の開始時に、チェックはすべての実行に対して成功としてマークされます。

ビジネス時間の終わりにステージの実行が開始されていない (他のチェックで保留されている) 場合、ビジネス時間の承認は自動的に取り消され、翌日に再評価がスケジュールされます。 チェックに指定されたタイムアウト期間内にステージの実行が開始されなかった場合はチェックは失敗し、ステージは失敗としてマークされます。

Azure 関数の呼び出し

Azure 関数は、Azure によって提供されるサーバーレスの評価プラットフォームです。 Azure 関数を使用すると、アプリケーションのインフラストラクチャについて気にすることなく、小さなコード (これを "関数" と言います) を実行することができます。 高い柔軟性を備えた Azure 関数では、独自のチェックを作成するための優れた方法を提供しています。 check-in Azure 関数のロジックを含めて、各実行が http 要求でトリガーされ、実行時間が短く、応答を返すようにします。 チェックの定義中に、応答本文を解析して、チェックの成功を推測できます。 評価は、管理オプションの [評価の間隔] 設定を使用して定期的に繰り返すことができます。 詳細情報

構成された タイムアウト内でチェックが成功しない場合、関連付けられているステージはスキップされます。 それに依存するステージもスキップされます。 詳細については、Azure 関数アプリ タスクを参照してください。

Azure 関数の呼び出しチェックを使用するためのおすすめの方法の詳細を参照してください。 チェックは、モードと準拠する再試行回数に応じて、特定の規則に従う必要があります。

REST API の呼び出し

REST API の呼び出しチェックでは、既存のサービスとの統合ができます。 定期的に REST API を呼び出し、成功の応答が返された場合は続行します。 詳細情報

評価は、管理オプションの [評価の間隔] 設定を使用して定期的に繰り返すことができます。 構成された タイムアウト内でチェックが成功しない場合、関連付けられているステージはスキップされます。 それに依存するステージもスキップされます。 詳細については、「REST API タスクの呼び出し」を参照してください。

REST API の呼び出しチェックを使用するためのおすすめの方法の詳細を参照してください。

Azure Monitor アラートのクエリ

Azure Monitor では、Azure インフラストラクチャと個々の Azure リソースから得られたデータを対象に、視覚化、クエリ、ルーティング、アラート、自動スケール、自動化が利用できます。 アラートは、インフラストラクチャまたはアプリケーションの正常性に関する問題を検出し、是正措置を取る標準的な手段です。 カナリア デプロイと段階的なロールアウトは、重要なアプリケーションへの回帰のリスクを減らすために使用される一般的なデプロイ戦略です。 ステージ (顧客のセット) にデプロイされた後、アプリケーションは一定期間観察されます。 デプロイ後のアプリケーションの正常性は、次のステージに更新の必要があるかどうかを決定するために使用されます。

Azure Monitor アラートのクエリでは、Azure Monitor を観察し、デプロイ後にアプリケーションに対してアラートが発生しないようにすることができます。 評価時にどのアラート ルールもアクティブにされていない場合、チェックは成功します。 詳細情報

評価は、管理オプションの [評価の間隔] 設定の後に繰り返されます。 ステージが指定されたタイムアウト期間内に実行を開始していない場合、チェックは失敗します。

必須テンプレート

必須テンプレートのチェックを使用すると、特定の YAML テンプレートを使用するようにパイプラインを適用できます。 このチェックが行われている場合、パイプラインが参照先のテンプレートから拡張されていない場合、パイプラインは失敗します。

必須テンプレートの承認を定義する方法は次のとおりです。

1. Azure DevOps プロジェクトで、制限するサービス接続に移動します。

2. [編集] の横にあるメニューから [承認とチェック] を開きます。

3. [最初のチェックの追加] メニューで、[必須テンプレート] を選択します。

4. 必須テンプレート ファイルにアクセスする方法の詳細を入力します。

   • [リポジトリの種類]: リポジトリの場所 (GitHub、Azure、または Bitbucket)。
   • [リポジトリ]: テンプレートを含むリポジトリの名前。
   • [参照]: 必須テンプレートのブランチまたはタグ。
   • [必須テンプレートへのパス]: テンプレートの名前。

同じサービス接続に対して複数の必須テンプレートを使用できます。 この例では、必須テンプレートは production_template.yaml です。

成果物の評価

カスタムポリシーに基づいて、環境に展開するアーティファクトを評価することができます。

アーティファクトに対するカスタム ポリシー評価を定義するには、次の手順を実行します。

1. Azure DevOps Services プロジェクトで、保護する必要のある環境に移動します。 環境の作成に関する詳細を確認してください。

   

2. 環境の [承認とチェック] に移動します。

   

3. [成果物の評価] を選択します。

   

4. ポリシー定義を貼り付け、「保存」を選択します。 ポリシー定義の記述に関して詳細を確認してください。

   

パイプラインを実行すると、その実行は、環境を使用するステージに入る前に一時停止します。 指定されたポリシーは、使用可能なイメージ メタデータに対して評価されます。 チェックは、ポリシーが成功すると成功し、それ以外の場合は失敗します。 チェックが失敗した場合、ステージは失敗としてマークされます。

排他ロック

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

ServiceNow Change Management

このチェックには、マーケットプレースからの ServiceNow Change Management 拡張機能のインストールが必要です

ServiceNow Change Management のチェックでは、ServiceNow の変更管理プロセスをパイプラインに統合できます。 チェックを追加すると、ServiceNow での新しい変更要求をステージの開始時に自動的に作成できます。 パイプラインでは、ステージを開始する前に、変更プロセスが完了するまで待機されます。 詳細はこちらをご覧ください。

複数の承認とチェック

ステージは多数のジョブで構成でき、各ジョブでは複数のリソースが消費される場合があります。 ステージの実行を開始する前に、そのステージで使用されるすべてのリソースのチェックをすべて満たす必要があります。 Azure Pipelines では、各ステージの前にパイプラインの実行が一時停止され、保留中のすべてのチェックが完了するまで待機します。

最終的に否定的な決定が 1 つあると、パイプラインのアクセスが拒否され、ステージが失敗します。 Azure 関数および REST API の呼び出しと排他ロックを除くすべての承認とチェックの決定は最終的なものです。 Azure 関数 / REST API のチェックの正常な呼び出しを再実行できます。

おすすめの方法で Azure 関数および REST API の呼び出しチェックを使用する場合、アクセスの決定も最終的なものです。

Azure 関数および REST API の呼び出しチェックで "評価の間隔" を 0 以外に指定する場合、チェックの決定は最終的なものではありません。 このシナリオは、精査する価値があります。

例を見てみましょう。 YAML パイプラインにサービス接続を使用するステージがあるとします。 このサービス接続には、次の 2 つのチェックが構成されています。

1. 外部の承認が付与されていること、および推奨される方法で構成されていることを検証する、External Approval Granted という名前の非同期チェック。
2. デプロイの理由が有効であり、"評価の間隔" が 7 分に設定されていることを検証する、Deployment Reason Valid という名前の同期チェック。

次の図に、考えられるチェックの実行を示しています。

この実行は、次のようになります。

• External Approval Granted および Deployment Reason Valid の両方のチェックが同時に呼び出されます。 Deployment Reason Valid はすぐに失敗しますが、External Approval Granted が保留となり、再試行されます。
• 7 分後、Deployment Reason Valid が再試行され、今度は成功します。
• 15 分後、External Approval Granted は Azure Pipelines にコールバックし、成功します。 これで、両方のチェックが成功したため、パイプラインはステージのデプロイを続行できます。

2 つの同期チェックを含む場合の別の例を見てみましょう。 YAML パイプラインにサービス接続を使用するステージがあるとします。 このサービス接続には、次の 2 つのチェックが構成されています。

1. "評価の間隔" が 5 分に設定された、Sync Check 1 という名前の同期チェック。
2. "評価の間隔" が 7 分に設定された、Sync Check 2 という名前の同期チェック。

次の図に、考えられるチェックの実行を示しています。

この実行は、次のようになります。

• Sync Check 1 および Sync Check 2 の両方のチェックが同時に呼び出されます。 Sync Check 1 は、合格しますが、再試行されます。これは、Sync Check 2 が失敗したためです。
• 5 分で、Sync Check 1 が再試行されますが、失敗するので、再試行されます。
• 7 分後、Sync Check 2 が再試行され、成功します。 成功の決定は 7 分間有効です。 この時間間隔で Sync Check 1 に合格しない場合は、Sync Check 2 が再試行されます。
• 10 分で、Sync Check 1 が再試行されますが、失敗するので、再試行されます。
• 14 分後、Sync Check 2 が再試行され、成功します。 成功の決定は 7 分間有効です。 この時間間隔で Sync Check 1 に合格しない場合は、Sync Check 2 が再試行されます。
• 15 分後、Sync Check 1 が再試行され、成功します。 これで、両方のチェックが成功したため、パイプラインはステージのデプロイを続行できます。

承認と同期チェックを含む場合の例を見てみましょう。 "評価の間隔" を 5 分に設定し、サービス接続に同期チェックと承認を構成したとします。 承認が与えられるまで、チェックは決定に関係なく5分ごとに実行されます。

よく寄せられる質問

定義されたチェックが開始されませんでした。 何が起きましたか?

チェックの評価は、ステージの条件が満たされた後に開始されます。 ステージの実行がリソースにチェックが追加された後に開始されたこと、およびそのステージでリソースが使用されていることを確認する必要があります。

ステージのスケジュール設定にチェックを使用するにはどうすればよいですか?

ビジネス時間のチェックを使用すれば、ステージ実行の開始時間をコントロールできます。 デザイナー リリースで、ステージでのスケジュール定義と同じことができます。

今後実行する予定のステージで事前承認を取得するにはどうすればよいですか?

このシナリオは有効にできます。

1. ビジネス時間のチェックを使用すると、リソースにデプロイするすべてのステージを時間枠の間に実行するようにスケジュールできます
2. 承認が同じリソースで構成されている場合、ステージは承認を待ってから開始されます。
3. リソースに対して両方のチェックを構成できます。 ステージは承認とビジネス時間を待機します。 承認が完了すると、次のスケジュールされた時間枠で開始されます。

デプロイされている成果物のセキュリティ スキャンが完了するまで待つことはできますか?

デプロイされている成果物のセキュリティ スキャンが完了するまで待つには、AquaScan などの外部スキャン サービスを使用する必要があります。 デプロイされている成果物は、チェックを開始する前にスキャン サービスからアクセスできる場所にアップロードする必要があり、これは定義済みの変数を使用して識別することができます。 REST API の呼び出しチェックを使用すると、セキュリティ サービスで API を待機し、成果物の識別子を入力として渡すチェックを追加できます。

チェックで前のステージの出力変数を使用するにはどうすればよいですか?

既定では、定義済みの変数のみをチェックに使用できます。 他の変数にアクセスするには、リンクされた変数グループを使用できます。 前のステージの出力変数を変数グループに書き込み、チェックでアクセスできます。

詳細情報

• Azure 関数/REST API チェックの呼び出し
• REST API の承認とチェック
• 承認クエリ REST API