トリガーを使用してパイプラインを実行するタイミングを制御する
これで、Bicep ファイルを Azure 環境にデプロイするパイプラインを使用できるようになりました。 ただし、ファイルを変更するたびに、パイプラインを手動で実行する必要があります。 このユニットでは、Bicep コードが変更されるたびにパイプラインをトリガーして、自動的に実行する方法について説明します。
注意
このユニットのコマンドは、概念を説明するために示されています。 コマンドはまだ実行しないでください。 ここで学習した内容をすぐに練習します。
パイプライン トリガーとは
パイプライン トリガーとは、それが満たされたときに、作成した規則に基づいてパイプラインを自動的に実行する条件です。 スケジュール設定した間隔でパイプラインを実行するようにトリガーを設定できます。 また、リポジトリ内のファイルが変更されるたびにパイプラインを実行するようにトリガーを設定することもできます。 コードが変更されるたびにすべてのテストおよびデプロイ ステップを実行するのはよい考えなので、2 番目のオプションを選択することをお勧めします。
自動トリガーを使用しない場合、だれかが Bicep ファイルに変更を加え、それをコミットしてリポジトリにプッシュするかもしれません。 しかし、そのユーザーがパイプラインの実行を忘れた場合、Bicep ファイル内のリソース定義と、Azure 環境にデプロイされているリソースとの間に違いが生じます。 さらにいくつかのコミットとプッシュが行われ、デプロイされなかったとします。 Bicep ファイルのこうした変更に誰かが組み込んだエラーや誤った構成がある場合、後で一括してデプロイされた複数のコミットの中からそのエラーを見つけ出すのは困難になる可能性があります。 しばらくすると、Bicep コードがお使いのインフラストラクチャを本当に表していることが確信できなくなり、その価値は損なわれます。
ファイルを更新するたびに実行されるようパイプラインを設定すると、変更がプッシュされた瞬間に、パイプラインの実行が開始されます。 変更の有効性についてすぐにフィードバックを受け取り、運用環境が常に最新の状態であることを確信できます。
ブランチ トリガー
一般的なトリガーの種類は、"ブランチ トリガー" です。これは "継続的インテグレーション トリガー" または "CI トリガー" とも呼ばれます。 ブランチ トリガーを使用すると、特定のブランチに変更を加えるたび、パイプラインが実行されます。 変更をコミットして別のブランチにプッシュした場合、パイプラインはトリガーされず、実行もされません。 次のコードを使用して、既定のブランチまたは "メイン" ブランチに対してこの種類のトリガーを使用するのが一般的です。
trigger:
- main
複数のブランチが変更されたときにトリガーする
特定のブランチ、またはブランチのセットに対してパイプラインを実行するようにトリガーを設定できます。 たとえば、プロジェクトの特定のリリース用にデプロイするコードを含む "リリース ブランチ" を作成するとします。 release/v1 や release/v2 などのブランチ名を使用できます。 名前が release/ で始まるブランチでコードが変更されるたびに、パイプラインを実行したいと思います。 include プロパティと * ワイルドカードを使用できます。
trigger:
branches:
include:
- main
- release/*
特定のブランチを除外することもできます。 たとえば、プロジェクトのチーム メンバーと共同作業をしているとします。 同僚は、Bicep ファイルでアイデアを試すための "機能ブランチ" を作成しました。 すべての機能ブランチには、feature/add-database や feature/improve-performance のような名前が付けられます。 同僚が作成した機能ブランチを除くすべてのブランチで、パイプラインを自動的に実行したいと考えています。 exclude プロパティを使用すると、機能ブランチへの変更に対してパイプラインが自動的にトリガーされないようにすることができます。
trigger:
branches:
include:
- '*'
exclude:
- feature/*
ヒント
include フィルター内のワイルドカードは引用符で囲まれていることがわかります。 YAML ファイル形式では、単一の * 文字をワイルドカードとして使用する場合は、引用符で囲む必要があります。
パス フィルター
場合によっては、デプロイに関係のないファイルがリポジトリに存在することがあります。 たとえば、リポジトリに、Bicep コードを含む deploy フォルダーと、ドキュメント ファイルを含む別の docs フォルダーがある場合があります。 だれかが deploy フォルダー内の Bicep ファイルに変更を加えたときはパイプラインをトリガーする必要がありますが、ドキュメント ファイルのみを変更したときはパイプラインをトリガーしたくありません。 リポジトリの特定のフォルダー内の変更に応答するようにトリガーを設定するには、"パス フィルター" を使用します。
trigger:
branches:
include:
- main
paths:
exclude:
- docs
include:
- deploy
ドキュメント ファイルのみを更新する変更をだれかがコミットした場合は、パイプラインは実行されません。 ただし、だれかが Bicep ファイルを変更した場合、またはドキュメント ファイルに加えて Bicep ファイルを変更した場合でも、トリガーによってパイプラインが実行されます。
自動的に実行するようにパイプラインをスケジュール設定する
ファイルの変更に応じてではなく、設定したスケジュールに基づいてパイプラインを実行できます。 たとえば、Bicep コードの夜間リリースを実行したり、毎朝テスト環境を自動的にデプロイしたりすることができます。 trigger の代わりに schedules キーワードを使用し、cron 式を使用してその頻度を設定します。
schedules:
- cron: "0 0 * * *"
displayName: Daily environment restore
branches:
include:
- main
Note
"cron 式" は、イベントが発生する頻度を設定する、特殊な形式の文字のシーケンスです。 この例では、0 0 * * * は "毎日午前 0 時 (UTC) に実行する" を意味します。
スケジュール設定したイベントで使用するようにリポジトリのブランチを設定することもできます。 パイプラインが開始されると、スケジュールで設定したブランチから最新バージョンのコードが使用されます。
複数のトリガーを使用する
次の例のように、トリガーとスケジュールを組み合わせることができます。
trigger:
- main
schedules:
- cron: "0 0 * * *"
displayName: Deploy test environment
branches:
include:
- main
同じパイプライン内にブランチ トリガー "および" スケジュールされたトリガーを作成すると、トリガーで設定したブランチでファイルが変更されるたび、"および" 設定したスケジュールに基づいて、パイプラインが実行されます。 この例では、パイプラインは毎日午前 0 時 (UTC) に実行されるのに加えて、"メイン" ブランチに変更がプッシュされるたびに実行されます。
ヒント
パイプラインごとにトリガーを設定することをお勧めします。 トリガーを設定しない場合、既定では、いずれかのブランチでいずれかのファイルが変更されるたびにパイプラインは自動的に実行されます。これは多くの場合、望ましい処理ではありません。
コンカレンシー制御
既定では、Azure Pipelines により、パイプラインの複数のインスタンスを同時に実行できます。 これは、ブランチに複数のコミットを短時間で行った場合に発生することがあります。
パイプラインの複数の同時実行は問題にならない場合もありますが、 デプロイ パイプラインを使用する場合は、パイプラインの実行により、予期しない方法で Azure のリソースまたは構成が上書きされないようにすることが困難な場合があります。
このような問題を回避するには、次の例のように、トリガーで batch キーワードを使用します。
trigger:
batch: true
branches:
include:
- main
トリガーが起動すると、Azure Pipelines により、すべてのアクティブなパイプラインの実行が完了するまで確実に待機するようになります。 次に、前回の実行以降に蓄積されたすべての変更とともに、新しい実行が開始されます。