デプロイをプレビューして承認する

5 分

パイプラインステージについて、およびパイプラインステージを追加して Bicep コードを検証する方法について学習しました。デプロイの信頼性を構築するための次のステップでは、別のステージを追加して、デプロイによって何が変更されるのかを厳密に確認します。

このユニットでは、パイプラインでの what-if コマンドを使用する方法について学習します。また、デプロイを実行する前にコマンドの出力を手動で確認できるように、承認を追加する方法についても学習します。

what-if 操作

Bicep ファイルには、デプロイの最後に Azure 環境がどのような状態になるかが記述されています。デプロイを送信すると、Azure Resource Manager により、Bicep ファイルに記述されている状態に合わせて Azure 環境が変更されます。

デプロイすると、新しいリソースが環境にデプロイされたり、既存のリソースが更新されたりする可能性があります。デプロイを完全モードで実行すると、既存のリソースが削除されることもあります。

リソースが作成、更新、または削除されると、予期しない方法で変更される可能性があるリスクがあります。作成、更新、削除されるリソースを確認するためにさらにステップを追加することをお勧めします。この検証によって、自動化プロセスの価値が高まります。運用環境にデプロイする場合は、環境に生じる変更を確認することが重要です。

Resource Manager では、what-if 操作が提供されます。これは、パイプラインステージ内の Bicep ファイルで実行できます。

Lint、Validate、Preview の各ステージを含むパイプラインの図。プレビューステージでは、Azure に対して What-If 操作が実行されます。

パイプライン定義で az deployment group what-if Azure CLI コマンドを使用して、what-if ステップを実行できます。

stages:

- stage: Preview
  jobs: 
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

ヒント

このモジュールでは、Azure CLI を使用して what-if 操作を実行します。 PowerShell ベースの独自のパイプラインを構築するには、New-AzResourceGroupDeployment コマンドレットと -Whatif スイッチを使用するか、Get-AzResourceGroupDeploymentWhatIfResult コマンドレットを使用します。

what-if 操作では、環境に対して変更が加えられることはありません。代わりに、作成されるリソース、更新されるリソースプロパティ、削除されるリソースが記述されます。

What-if では、変更が実際には発生しないのにリソースが変更されることが示される場合があります。このフィードバックは "ノイズ" と呼ばれます。これらの問題の削減に取り組んでいます。ここで問題を報告できます。

what-if 操作の出力が表示されたら、デプロイを続行するかどうかを決定できます。通常、この手順では、what-if コマンドからの出力を人間が確認し、識別された変更が妥当かどうかを判断します。変更が妥当であるとレビュー担当者が判断した場合は、パイプラインの実行を手動で承認できます。

環境

Azure Pipelines では、"環境" はソリューションがデプロイされる場所を表します。環境には、複雑なデプロイを行うときに役立つ機能が用意されています。今後のモジュールでは、環境とその機能について詳しく学習します。ここでは、パイプラインに手動承認を追加する機能に重点を置いて説明します。

既にわかっているとおり、ジョブを使用して、パイプラインステージ内の一連のステップを定義します。パイプラインに環境を含める場合は、"デプロイジョブ" と呼ばれる特別な種類のジョブを使用する必要があります。デプロイジョブは通常ジョブに似ていますが、いくつかの追加機能が用意されています。この機能には、デプロイジョブで使用する環境の定義が含まれます。

variables:
  - name: deploymentDefaultLocation
    value: westus3

stages:

- stage: Preview
  jobs:
  - job: Preview
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'MyServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az deployment group what-if \
            --resource-group $(ResourceGroupName) \
            --template-file deploy/main.bicep

- stage: Deploy
  jobs:
    - deployment: Deploy
      environment: MyAzureEnvironment
      strategy:
        runOnce:
          deploy:
            steps:
            - checkout: self

            - task: AzureResourceManagerTemplateDeployment@3
              name: Deploy
              displayName: Deploy to Azure
              inputs:
                connectedServiceName: 'MyServiceConnection'
                location: $(deploymentDefaultLocation)
                resourceGroupName: $(ResourceGroupName)
                csmFile: deploy/main.bicep

デプロイジョブの YAML 定義には、通常のジョブといくつかの主な違いがあることに注意してください。

デプロイジョブは、job という語で始まるのではなく、deployment として定義されます。
environment キーワードにより、対象となる環境の名前が指定されます。前の例では、デプロイは MyAzureEnvironment という名前の環境に対して追跡されます。
strategy キーワードにより、Azure Pipelines でデプロイステップがどのように実行されるかが指定されます。デプロイ戦略では、特に複数の運用環境がある場合に、複雑なデプロイプロセスがサポートされます。このモジュールでは、 runOnce デプロイ戦略を使用します。この方法は、既に慣れている他のジョブと同様に動作します。

ステージのチェックと承認

環境を作成した後、"チェック" を定義できます。チェックを使用して、パイプラインで環境を使用する前に満たす必要がある条件を検証します。承認とは、手動による承認を人間が行う必要があるチェックの一種です。

チェックは、パイプラインではなく、環境で定義されます。パイプライン YAML ファイルの作成者は、これらのチェックや承認を削除したり追加したりすることはできません。チェックと承認を管理できるのは、その環境の管理者だけです。

多くの組織では、Azure Pipelines の環境の所有者は、デプロイ先の環境の責任者です。チェックと承認は、デプロイプロセスに適切な人材が携わっていることを確認するのに役立ちます。

チェックと承認のしくみ

チェックと承認は、パイプラインステージが開始される直前に評価されます。 Azure Pipelines は、パイプラインステージを実行しようとしているときに、ステージで使用されるすべてのパイプラインリソース (環境を含む) を確認します。環境では、満たす必要のあるチェックを行うことができます。

承認は、チェックの一種です。承認チェックを構成するときは、パイプラインの継続を承認する必要があるレビュー担当者を 1 人以上割り当てます。

Azure Pipelines には、他の種類のチェックも用意されています。たとえば、API を呼び出してカスタムロジックを実行したり、ステージを実行できる営業時間を制御したり、Azure Monitor にクエリを実行してデプロイが成功したことを確認したりできます。このモジュールでは承認チェックについてのみ説明しますが、モジュールの概要にはチェックに関する詳細情報へのリンクが含まれています。

注

エージェントプールとサービス接続に、それらのチェックを構成することもできます。 手動承認タスクと呼ばれる特別なステップを使用することもできます。ただし、このモジュールでは、環境とそれらに関連付けられているチェックに重点を置いています。

パイプラインが開始され、承認チェックを必要とするステージに到達すると、パイプラインの実行は一時停止します。承認者として指定されたすべての校閲者には、Azure DevOps と電子メールでメッセージが送信されます。

承認者は、パイプラインログで、what-if 操作によって検出された変更などを検査できます。次に、この情報に基づいて、変更を承認または拒否します。変更を承認すると、パイプラインが再開されます。これらのユーザーが拒否した場合、または構成可能なタイムアウト期間内に応答しなかった場合、ステージは失敗します。

Lint、Validate、Preview、Deploy の各ステージを含むパイプラインの図。デプロイステージの前に承認チェックがあります。

ベストプラクティスの重要性

Azure Pipelines の環境機能を使用すると、デプロイを環境にリンクできます。その後、デプロイは、環境の所有者によって定義されたチェックと承認を継承します。ただし、新しいパイプラインで環境を使用する必要はありません。

自分と組織がパイプライン定義を確認するためのグッドプラクティスを確立することが重要です。たとえば、ブランチ保護ポリシーを使用して、メイン ブランチへの変更に関するプル要求の確認を要求するようにリポジトリを構成します。この概念については、今後のモジュールで学習します。

また、サービス接続にチェックと承認を追加して、デプロイでサービスプリンシパルの資格情報を使用する前に承認を確実に取得することもできます。ただし、承認は、サービス接続も必要であるため、プレフライト検証と what-if 操作を実行するパイプラインの機能にも影響します。

独自のサービスプリンシパルに基づいて、what-if ステージに他の個別のサービス接続を使用することもできます。プレフライトステージと検証ステージに使用されるサービスプリンシパルには、作業に必要な最小限のアクセス許可を確実に持つカスタム Azure ロールが定義されている必要があります。

フィードバック

このページはお役に立ちましたか?