承認とチェックを定義する
Azure DevOps Services
パイプラインは、ステージで構成されます。 パイプライン作成者は、ステージで条件を定義することで、ステージを実行するかどうかを制御できます。 ステージを実行するかどうかと、そのタイミングを制御するもう 1 つの方法は、承認とチェックを使用することです。
承認やその他のチェックは、yaml ファイルでは定義されません。 パイプラインの yaml ファイルを変更しているユーザーは、ステージの開始前に実行されるチェックを変更できません。 リソースの管理者は、Azure Pipelines の Web インターフェイスを使用してチェックを管理します。
パイプラインは、環境、サービス接続、エージェント プール、変数グループ、セキュリティで保護されたファイルなどのリソースに依存します。 チェックを使用すると、"リソースの所有者" は、任意のパイプラインのステージでリソースを消費できるかどうかとそのタイミングを制御できます。 リソースの所有者は、そのリソースを消費するステージを開始する前に満たす必要があるチェックを定義できます。 例えば、環境に対する手動承認チェックは、指定されたユーザーがデプロイされる変更をレビューした後にのみ、その環境へのデプロイが行われることを保証します。
ステージは多数のジョブで構成でき、各ジョブでは複数のリソースが消費される場合があります。 ステージの実行を開始する前に、そのステージで使用されるすべてのリソースのチェックをすべて満たす必要があります。 Azure Pipelines では、各ステージの前にパイプラインの実行が一時停止され、保留中のすべてのチェックが完了するまで待機します。
承認とチェックには5つのカテゴリがあり、各カテゴリ内で作成された順序で実行されます。 チェックは、各チェックで指定された再試行のサイクル間隔に基づいて再評価されます。 タイムアウトが指定されるまですべてのチェックが完了しない場合、そのステージは実行されません。 いずれかのチェックが最終的に失敗した場合 (たとえば、いずれかのリソースで承認を拒否した場合など)、そのステージは実行されません。 ただし、承認とチェックがタイムアウトになった場合は、ステージを再試行できます。
静的チェックが最初に実行され、次に事前チェックの承認が実行されます。 次のカテゴリが順番に表示されます。
- 静的チェック：分岐制御、必要なテンプレートと評価アーティファクト
- 事前チェック承認
- ダイナミックチェック：承認、Azure関数の呼び出し、REST APIの呼び出し、営業時間、Azure Monitorアラートの照会
- チェック後の承認
- 排他ロック
「承認とチェック」タブにも実行順序が表示されます。
重要
チェックは、環境、サービス接続、リポジトリ、変数グループ、セキュリティで保護されたファイル、エージェント プールで構成できます。
サービス接続を変数で指定することはできません。
承認
承認チェックを使用することにより、ステージを実行するタイミングを手動で制御できます。 このチェックは一般的に、運用環境へのデプロイを制御するために使用されます。
Azure DevOps 組織にサインインしてから、プロジェクトに移動します。
Pipelines>環境を選択し、続いてお使いの環境を選択します。
[承認とチェック] タブを選択して、+記号を選択し、新しいチェックを追加します。
[承認] を選択し、 [次へ] を選択します。
ユーザーまたはグループを、指定された 承認者として追加し、必要に応じて、承認者に指示を提供します。 承認者による独自の実行を承認することを許可または制限するかどうかを指定して、目的の タイムアウトを指定します。 指定したタイムアウト内に承認が完了しない場合、ステージは [スキップ] としてマークされます。
終わったら [作成] を選択します。
承認チェックがトリガーされると、次の例に示すように、ユーザー インターフェイスにプロンプト ウィンドウが表示されます。 このウィンドウには、承認者が実行を拒否または承認できるオプションと、それに付随する指示が表示されます。
承認を確認できるユーザーのリストは、承認とチェックの実行が開始された時点で固定されます。 つまり、チェックの実行開始後に行われた承認チェックのユーザーおよびグループのリストへの変更はピックアップされません。
Note
グループが承認者として指定されている場合、実行を続行するために承認することが必要となるのは、グループ内の 1 人のユーザーのみです。
承認の延期
承認が付与された時間と展開を開始する時間が一致しない場合があります。 たとえば、夕方にトラフィックが少なくなるまで、新しいリリースの展開を待機することができます。
このシナリオに対処するには、承認を延期し、承認が有効になる時間を設定します。
「承認の延期」を選択します。
承認時間を設定します。
事前承認として「チェック」パネルに承認が表示されます。 決められた時間に承認が有効になります。
ブランチ コントロール
ブランチ コントロール チェックを使用すると、パイプラインにリンクされているすべてのリソースが許可されたブランチからビルドされ、そのブランチで保護が有効になっていることを確認できます。 このチェックは、リリースの準備とデプロイの品質を制御するのに役立ちます。 パイプラインに複数のリソースがリンクされている場合は、すべてのリソースのソースが検証されます。 別のパイプラインをリンクしている場合は、デプロイされている特定の実行のブランチが保護用に検証されます。
ブランチ コントロール チェックを定義する方法は次のとおりです。
Azure DevOps プロジェクトで、保護する必要のあるリソース (たとえば、環境など) に移動します。
リソースの [承認とチェック] に移動します。
[ブランチ コントロール]チェックを選択し、許可されたブランチのコンマ区切りの一覧を指定します。 ブランチで保護の有効を義務付けることができます。 いずれかのブランチの保護状態が不明な場合に備えて、チェックの動作を定義することもできます。
実行時に、チェックによって、許可されたリストに対して、実行内のすべてのリンクされたリソースのブランチが検証されます。 いずれかのブランチが条件と一致しない場合、チェックは失敗し、ステージは失敗とマークされます。
注意
チェックでは、ブランチ名を完全修飾にする必要があります。 ブランチ名の形式が refs/heads/<branch name> であることを確認します。
[営業時間]
環境へのすべてのデプロイを特定の時間枠でのみ行う場合は、ビジネス時間チェックが最適なソリューションです。 パイプラインを実行すると、リソースを使用するステージの実行はビジネス時間まで待機されます。 複数の実行が同時に実行されている場合は、各実行は個別に検証されます。 ビジネス時間の開始時に、チェックはすべての実行に対して成功としてマークされます。
ビジネス時間の終わりにステージの実行が開始されていない (他のチェックで保留されている) 場合、ビジネス時間の承認は自動的に取り消され、翌日に再評価がスケジュールされます。 チェックに指定されたタイムアウト期間内にステージの実行が開始されなかった場合はチェックは失敗し、ステージは失敗としてマークされます。
Azure 関数の呼び出し
Azure 関数は、Azure によって提供されるサーバーレスの評価プラットフォームです。 Azure 関数を使用すると、アプリケーションのインフラストラクチャについて気にすることなく、小さなコード (これを "関数" と言います) を実行することができます。 高い柔軟性を備えた Azure 関数では、独自のチェックを作成するための優れた方法を提供しています。 http 要求で各実行がトリガーされ、実行時間が短く、応答が返されるように、チェックイン Azure 関数のロジックを含めます。 チェックの定義中に、応答本文を解析して、チェックの成功を推測できます。 評価は、管理オプションの [評価の間隔] 設定を使用して定期的に繰り返すことができます。 詳細情報
構成された タイムアウト内でチェックが成功しない場合、関連付けられているステージはスキップされます。 それに依存するステージもスキップされます。 詳細については、Azure 関数アプリ タスクを参照してください。
Note
ユーザー定義のパイプライン変数には、Sprint 215 以降のチェックにアクセスできます。
Azure 関数の呼び出しチェックを使用するためのおすすめの方法の詳細を参照してください。 チェックは、モードと準拠する再試行回数に応じて、特定の規則に従う必要があります。
REST API の呼び出し
REST API の呼び出しチェックでは、既存のサービスとの統合ができます。 定期的に REST API を呼び出し、成功の応答が返された場合は続行します。 詳細情報
評価は、管理オプションの [評価の間隔] 設定を使用して定期的に繰り返すことができます。 構成された タイムアウト内でチェックが成功しない場合、関連付けられているステージはスキップされます。 それに依存するステージもスキップされます。 詳細については、「REST API タスクの呼び出し」を参照してください。
Note
ユーザー定義のパイプライン変数には、Sprint 215 以降のチェックにアクセスできます。
REST API の呼び出しチェックを使用するためのおすすめの方法の詳細を参照してください。
Azure Monitor アラートのクエリ
Azure Monitor では、Azure インフラストラクチャと個々の Azure リソースから得られたデータを対象に、視覚化、クエリ、ルーティング、アラート、自動スケール、自動化が利用できます。 アラートは、インフラストラクチャまたはアプリケーションの正常性に関する問題を検出し、是正措置を取る標準的な手段です。 カナリア デプロイと段階的なロールアウトは、重要なアプリケーションへの回帰のリスクを減らすために使用される一般的なデプロイ戦略です。 ステージ (顧客のセット) にデプロイされた後、アプリケーションは一定期間観察されます。 デプロイ後のアプリケーションの正常性は、次のステージに更新の必要があるかどうかを決定するために使用されます。
Azure Monitor アラートのクエリでは、Azure Monitor を観察し、デプロイ後にアプリケーションに対してアラートが発生しないようにすることができます。 評価時にどのアラート ルールもアクティブにされていない場合、チェックは成功します。 詳細情報
評価は、管理オプションの [評価の間隔] 設定の後に繰り返されます。 ステージが指定されたタイムアウト期間内に実行を開始していない場合、チェックは失敗します。
必須テンプレート
必須テンプレートのチェックを使用すると、特定の YAML テンプレートを使用するようにパイプラインを適用できます。 このチェックが行われている場合、パイプラインが参照先のテンプレートから拡張されていない場合、パイプラインは失敗します。
必須テンプレートの承認を定義する方法は次のとおりです。
Azure DevOps プロジェクトで、制限するサービス接続に移動します。
[編集] の横にあるメニューから [承認とチェック] を開きます。
[最初のチェックの追加] メニューで、[必須テンプレート] を選択します。
必須テンプレート ファイルにアクセスする方法の詳細を入力します。
- [リポジトリの種類]: リポジトリの場所 (GitHub、Azure、または Bitbucket)。
- [リポジトリ]: テンプレートを含むリポジトリの名前。
- [参照]: 必須テンプレートのブランチまたはタグ。
- [必須テンプレートへのパス]: テンプレートの名前。
同じサービス接続に対して複数の必須テンプレートを使用できます。 この例では、必須テンプレートは production_template.yaml です。
チェックを無効にする
チェックをデバッグするときに、一時的に無効にしてから再度有効にすることができます。 チェックを無効または有効にするには:
Azure DevOps プロジェクトで、チェックを持ってリソースに移動します。
[承認とチェック] タブを開きます。
コンテキスト メニューで、[無効] または [有効] を選択します。
チェックをバイパスする
修正プログラムの展開の際などに、チェックをバイパスすることが必要になる場合があります。 チェックが定義されている場合にリソースの管理者権限がある場合にのみ、チェックをバイパスすることができます。
承認、営業時間、Azure 関数の呼び出し、REST API チェックの呼び出しをバイパスするには、リソースがレビュー待ちをしているときに [チェックをバイパスする] を選択します。 営業時間のチェックをバイパスする例を次に示します。
チェックをバイパスすると、チェックをバイパスしたユーザーがチェック パネル内に表示されます。
成果物の評価
カスタムポリシーに基づいて、環境に展開するアーティファクトを評価することができます。
Note
現時点では、これはコンテナー イメージの成果物でのみ機能します
アーティファクトに対するカスタム ポリシー評価を定義するには、次の手順を実行します。
Azure DevOps Services プロジェクトで、保護する必要のある環境に移動します。 環境の作成に関する詳細を確認してください。
環境の [承認とチェック] に移動します。
[成果物の評価] を選択します。
ポリシー定義を貼り付け、「保存」を選択します。 ポリシー定義の記述に関して詳細を確認してください。
パイプラインを実行すると、その実行は、環境を使用するステージに入る前に一時停止します。 指定されたポリシーは、使用可能なイメージ メタデータに対して評価されます。 チェックは、ポリシーが成功すると成功し、それ以外の場合は失敗します。 チェックが失敗した場合、ステージは失敗としてマークされます。
排他ロック
排他ロックのチェックでは、パイプラインからの 1 つの実行のみを続行できます。 リソースを使用するパイプラインのすべての実行の全ステージが一時停止されます。 ロックを使用するステージが完了すると、別のステージがリソースを使用できるようになります。 また、継続できるステージは1つだけです。
ロックの取得を試みる他のステージの動作は、パイプラインの YAML ファイルに構成された lockBehavior 値によって構成されます。
runLatest- 最新の実行のみが、リソースへのロックを取得します。runLatestが指定されていない場合、lockBehaviorが既定値です。sequential- すべての実行で、保護されたリソースに対して順番にロックが取得されます。
sequential デプロイまたは runLatest で排他ロックのチェックを使用するには、次の手順に従います。
- 環境 (または別の保護されたリソース) で排他ロックのチェックを有効にします。
- パイプラインの YAML ファイルで、
lockBehaviorというプロパティを指定します。 これは、パイプライン全体または特定のステージに対して指定できます。
ステージに設定する場合:
stages:
- stage: A
lockBehavior: sequential
jobs:
- job: Job
steps:
- script: Hey!
パイプラインに設定する場合:
lockBehavior: runLatest
stages:
- stage: A
jobs:
- job: Job
steps:
- script: Hey!
lockBehavior を指定しない場合、既定値の runLatest が使用されます。
排他ロックのチェックでは、パイプラインからの 1 つの実行のみを続行できます。 リソースを使用するパイプラインのすべての実行の全ステージが一時停止されます。 ロックを使用するステージが完了すると、別のステージがリソースを使用できるようになります。 また、継続できるステージは1つだけです。 ロックの取得を試みた他のステージはすべてキャンセルされます。
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 つのチェックが構成されています。
- 外部の承認が付与されていること、および推奨される方法で構成されていることを検証する、External Approval Granted という名前の非同期チェック。
- デプロイの理由が有効であり、"評価の間隔" が 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 つのチェックが構成されています。
- "評価の間隔" が 5 分に設定された、Sync Check 1 という名前の同期チェック。
- "評価の間隔" が 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分ごとに実行されます。
よく寄せられる質問
定義されたチェックが開始されませんでした。 何が起きましたか?
チェックの評価は、ステージの条件が満たされた後に開始されます。 ステージの実行がリソースにチェックが追加された後に開始されたこと、およびそのステージでリソースが使用されていることを確認する必要があります。
ステージのスケジュール設定にチェックを使用するにはどうすればよいですか?
ビジネス時間のチェックを使用すれば、ステージ実行の開始時間をコントロールできます。 デザイナー リリースで、ステージでのスケジュール定義と同じことができます。
今後実行する予定のステージで事前承認を取得するにはどうすればよいですか?
このシナリオは有効にできます。
- ビジネス時間のチェックを使用すると、リソースにデプロイするすべてのステージを時間枠の間に実行するようにスケジュールできます
- 承認が同じリソースで構成されている場合、ステージは承認を待ってから開始されます。
- リソースに対して両方のチェックを構成できます。 ステージは承認とビジネス時間を待機します。 承認が完了すると、次のスケジュールされた時間枠で開始されます。
デプロイされている成果物のセキュリティ スキャンが完了するまで待つことはできますか?
デプロイされている成果物のセキュリティ スキャンが完了するまで待つには、AquaScan などの外部スキャン サービスを使用する必要があります。 デプロイされている成果物は、チェックを開始する前にスキャン サービスからアクセスできる場所にアップロードする必要があり、これは定義済みの変数を使用して識別することができます。 REST API の呼び出しチェックを使用すると、セキュリティ サービスで API を待機し、成果物の識別子を入力として渡すチェックを追加できます。
チェックで前のステージの出力変数を使用するにはどうすればよいですか?
既定では、定義済みの変数のみをチェックに使用できます。 他の変数にアクセスするには、リンクされた変数グループを使用できます。 前のステージの出力変数を変数グループに書き込み、チェックでアクセスできます。
詳細情報
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示