パイプラインテンプレートを使用して、環境間の類似に対応する

5 分

変更を複数の環境にデプロイする場合、各環境へのデプロイに関連する手順は、似ているか同じです。このユニットでは、パイプラインテンプレートを使用して繰り返しを避け、パイプラインコードの再利用を可能にする方法について学びます。

複数の環境へのデプロイ

Web サイトチームの同僚と話し合ってから、あなたは玩具会社の Web サイトで次のパイプラインを使用することに決めました。

テスト環境と運用環境へのデプロイを含む一連のパイプラインステージを示す図。

パイプラインは、Bicep リンターを実行して、Bicep コードが有効でベストプラクティスに従っていることをチェックします。

リンティングは、Azure に接続せずに Bicep コードに対して実行できるため、いくつの環境にデプロイしようとしているかに関わらず、一度だけ実行されます。
このパイプラインはテスト環境にデプロイされます。このステージでは次が必要です。
1. Azure Resource Manager プレフライト検証の実行。
2. Bicep コードのデプロイ。
3. テスト環境に対する、いくつかのテストの実行。
パイプラインの一部が失敗すると、問題を調査して解決できるようにパイプライン全体が停止します。すべてが成功した場合、パイプラインは運用環境へのデプロイを継続します。
1. パイプラインでプレビューステージが実行されます。このステージでは、運用環境で What-If 操作が実行されて、運用 Azure リソースに対して行われる変更の一覧が表示されます。プレビューステージではデプロイの検証も行われるため、運用環境に対して別の検証ステージを実行する必要はありません。
2. 手動の検証のために、パイプラインは一時停止します。
3. 承認が得られたら、パイプラインは運用環境に対してデプロイとスモークテストを実行します。

ステージの一部はテスト環境と運用環境で繰り返され、別の一部は特定の環境に対してのみ実行されます。

段階	環境
リント	どちらでもない - リンティングは、環境に対して動作しません
検証	テスト環境のみ
プレビュー	運用環境のみ
デプロイ	両方の環境
スモークテスト	両方の環境

パイプライン内でステップを繰り返す必要がある場合、ステップの定義をコピーして貼り付けることもできます。ただし、そのようなことは避けるのが最善です。わずかな間違いが入り込むおそれがありますし、パイプラインのコードを複製するときに、一部が同期されなくなってしまうこともあり得ます。また、将来ステップを変更する必要が生じたときに、変更を複数の場所に適用しなければならなくなります。

パイプラインテンプレート

パイプラインテンプレートを使用すると、パイプライン定義の再利用可能なセクションを作成できます。テンプレートでは、ステップ、ジョブ、さらにステージ全体を定義することができます。テンプレートを使用することで、単一のパイプライン内もしくは複数のパイプラインで、パイプラインの一部を複数回再利用できます。また、複数のパイプラインで再利用したい一連の変数のテンプレートを作成することもできます。

テンプレートは、再利用可能なコンテンツを含む通常の YAML ファイルです。ステップ定義のシンプルなテンプレートは次のようなもので、script.yml という名前のファイルに保存できます。

steps:
- script: |
    echo Hello world!

パイプラインでは、通常個々のステップを定義する場所で template キーワードを使用することにより、テンプレートを使用できます。

jobs:
- job: Job1
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: script.yml

- job: Job2
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: script.yml

入れ子になったテンプレート

テンプレートを他のテンプレート内で入れ子にすることもできます。以前のファイル名が jobs.yml で、複数のパイプラインステージでジョブテンプレートを再利用する azure-pipelines.yml という名前のファイルを作成するとします。

trigger:
  branches:
    include:
    - main

pool:
  vmImage: ubuntu-latest

stages:

- stage: Stage1
  jobs:
  - template: jobs.yml

- stage: Stage2
  jobs:
  - template: jobs.yml

テンプレートを入れ子にする場合、または単一のパイプラインでそれらを複数回再利用する場合、複数のパイプラインリソースで誤って同じ名前を使用しないように注意する必要があります。たとえば、ステージ内の各ジョブには、独自の識別子が必要です。テンプレート内でジョブ識別子を定義する場合、同じステージ内で複数回再利用することはできません。

複数の複雑なデプロイパイプラインを扱う場合、共有パイプラインテンプレートのための専用の Git リポジトリを作成すると便利です。そうすれば、異なるプロジェクトのものであっても、複数のパイプラインで同じリポジトリを再利用できます。概要にある詳細へのリンクを参照してください。

パイプラインテンプレートパラメーター

パイプラインテンプレートパラメーターを使用すると、テンプレートファイルの再利用が簡単になります。テンプレートを使用する際に少しだけ変化させることができるからです。

パイプラインテンプレートを作成する際に、ファイルの上部でパラメーターを明示できます。

parameters: 
- name: environmentType
  type: string
  default: 'Test'
- name: serviceConnectionName
  type: string

必要な数のパラメーターを定義できます。 Bicep パラメーターと同じように、パイプラインテンプレートパラメーターは使いすぎないようにしてください。他の人が、多くの設定を行わなくてもテンプレートを簡単に再利用できるようにする必要があります。

各パイプラインテンプレートパラメーターには 3 つのプロパティがあります。

テンプレートファイル内でパラメーターを参照するために使用する、パラメーターの名前。
パラメーターの型。パラメーターは、文字列、数値、ブール値を含む、いくつかのデータ型をサポートしています。また、構造化されたオブジェクトを受け取れる、もっと複雑なテンプレートを定義することもできます。
パラメーターの "既定値" (省略可能)。既定値を指定しない場合、パイプラインテンプレートを使用する際に値を指定する必要があります。

この例では、パイプラインによって、既定値が Test の environmentType という名前の文字列パラメーターと、serviceConnectionName という名前の必須パラメーターが定義されています。

パイプラインテンプレートでは、パラメーターの値を参照する特殊な構文を使用します。次の例のように、${{parameters.YOUR_PARAMETER_NAME}} マクロを使用します。

steps:
- script: |
    echo Hello ${{parameters.environmentType}}!

次の例のように、parameters キーワードを使用して、パラメーターの値をパイプラインテンプレートに渡します。

steps:
- template: script.yml
  parameters:
    environmentType: Test

- template: script.yml
  parameters: 
    environmentType: Production

パイプラインテンプレートでジョブとステージに識別子を割り当てる際に、パラメーターを使用することもできます。この手法は、次のように、パイプラインで同じテンプレートを複数回再利用する必要がある場合に役立ちます。

parameters:
- name: environmentType
  type: string
  default: 'Test'

jobs:
- job: Job1-${{parameters.environmentType}}
  pool:
    vmImage: 'windows-latest'
  steps:
  - template: script.yml

- job: Job2-${{parameters.environmentType}}
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - template: script.yml

条件

パイプラインの条件を使用すると、ステップ、ジョブ、ステージを、指定したルールに基づいて実行させるかどうかを指定できます。テンプレートパラメーターとパイプラインの条件を組み合わせて、デプロイプロセスを多くの状況に合わせてカスタマイズできます。

たとえば、スクリプトのステップを実行するパイプラインテンプレートを定義する状況を考えてみてください。それぞれの環境で、テンプレートを再利用する予定です。運用環境をデプロイするときは、別のステップを実行することもできます。 if マクロと、eq (等価) 演算子を使用してこれを実現する方法を次に示します。

parameters: 
- name: environmentType
  type: string
  default: 'Test'

steps:
- script: |
    echo Hello ${{parameters.environmentType}}!

- ${{ if eq(parameters.environmentType, 'Production') }}:
  - script: |
      echo This step only runs for production deployments.

この条件は、"environmentType パラメーターの値が Production に等しい場合は、以降の手順を実行する" という意味になります。

ヒント

この例のような条件を使うときは、YAML ファイルのインデントに注意してください。条件が適用されるステップには、もう一段階インデントを行う必要があります。

ステージ、ジョブ、ステップに対して、condition プロパティを指定することもできます。次に示すのは、ne ("等しくない") 演算子を使用して、"environmentType パラメーターの値が Production に等しくない場合は、以降の手順を実行する" のような条件を指定する方法の例です。

- script: |
    echo This step only runs for non-production deployments.
  condition: ne('${{ parameters.environmentType }}', 'Production')

条件を使用することでパイプラインに柔軟性を与えることができますが、使いすぎないようにご注意ください。パイプラインが複雑になり、流れを把握することが難しくなります。パイプラインテンプレートに多くの条件が含まれている場合、テンプレートは実行しようとしているワークフローに最善のソリューションではない可能性があり、パイプラインの再設計が必要かもしれません。

また、YAML のコメントを使用して、使用している条件や、説明が必要なパイプラインの他の要素について説明することも検討してください。コメントを使用することでパイプラインの理解が容易になり、将来も扱いやすくなります。このモジュールの演習には、YAML のコメントの例があります。

パイプライン テンプレートを使用して、環境間の類似に対応する

複数の環境へのデプロイ

パイプライン テンプレート

入れ子になったテンプレート

パイプライン テンプレート パラメーター

条件

フィードバック

パイプラインテンプレートを使用して、環境間の類似に対応する

パイプラインテンプレート

パイプラインテンプレートパラメーター