ワークフローとバージョン管理戦略を設計する

  • 7 分

再利用可能な Bicep コードの発行を開始するときには、手動のアプローチを使用するものと思われます。 発行する必要がある Bicep ファイルの判別は簡単で、バージョン番号をインクリメントするための手動のプロセスを設けることになるでしょう。

発行プロセスを自動化する場合には、これらの手順を自動化する方法を検討する必要があります。 このユニットでは、コードに加えた変更を明示するバージョン管理システムを採用する方法について説明します。 また、ワークフローのスコープを設定して、想定されるコードのみを発行する方法についても説明します。

バージョン番号

以前の Microsoft Learn トレーニング モジュールで、テンプレート スペックと Bicep モジュールのバージョン管理の重要性について学習しました。 バージョン管理のアプローチにはさまざまな選択肢があります。 多くの場合においては、"マルチパート" バージョン管理システムを使用することをお勧めします。 マルチパート バージョン管理システムは、次の例のように、"メジャー" バージョン、"マイナー" バージョン、"リビジョン" 番号で構成されます。

Diagram that shows the version number 1.4.106.

前の例では、メジャー バージョンは 1、マイナー バージョンは 4、リビジョン番号は 106 です。

バージョン番号の各部分の変更は、コードの変更の種類に関する重要な情報を明示します。

  • 重大な変更を加えるときには、メジャー バージョン番号をインクリメントする必要があります。 たとえば、新しい必須パラメーターを追加したり、Bicep ファイルからパラメーターを削除したりするとします。 これらは重大な変更の例です。Bicep では、必須パラメーターはデプロイ時に指定する必要があり、存在しないパラメーターには値を設定できないためです。 そのため、メジャー バージョン番号を更新します。

  • コードに何らかの新規の内容を追加しても、それが重大な変更ではない場合には、マイナー バージョン番号をインクリメントする必要があります。 たとえば、既定値が設定されている新しい省略可能なパラメーターを追加するとします。 省略可能なパラメーターは重大な変更ではないため、マイナー バージョン番号を更新する必要があります。

  • 下位互換性のためのバグ修正や、コードの動作に影響を与えないその他の変更を行う場合は、リビジョン番号をインクリメントする必要があります。 たとえば、Bicep コードをリファクタリングして、変数と式をより適切に使用するとします。 リファクタリングによって Bicep コードの動作がまったく変更されない場合は、リビジョン番号を更新します。

  • ワークフローでもリビジョン番号を自動的に設定することができます。 ワークフローの実行番号をリビジョン番号として使用できます。 この規則は、バージョン番号の他のコンポーネントを更新しない場合でも、バージョン番号が常に一意であることを保証するのに役立ちます。

たとえば、他のユーザーが発行した Bicep モジュールを使用しているとします。 モジュールのバージョン番号は 2.0.496 です。 モジュールの新しいバージョンとして、バージョン番号 2.1.502 を使用できることがわかります。 意味を持つ唯一の変更は、マイナー バージョン番号に対してです。これは、その新しいバージョンを使用するときに重大な変更を想定する必要がないことを示しています。

Note

"セマンティック バージョン管理" は、マルチパート バージョン管理に似た形式のバージョン管理構造です。 セマンティック バージョン管理には、バージョン番号に追加のコンポーネントが含まれ、各コンポーネントを設定または再設定するタイミングに関する厳密な規則があります。 セマンティック バージョン管理に関する詳細情報へのリンクを「まとめ」に示します。

チームは、バージョン管理のため、重大な変更をどう定義するかを決定する必要があります。 たとえば、ストレージ アカウントをデプロイする Bicep ファイルを作成したとします。 ここで Bicep ファイルを更新して、ストレージ アカウントでプライベート エンドポイントを有効にしようとしています。 同時に、プライベート DNS ゾーンを Bicep ファイルに追加しようとしています。

この例では、Bicep ファイルのパラメーターまたは出力に影響を与えることなく変更を加えることができるかもしれません。 そうした場合、ファイルをデプロイするユーザーは、違いがあることに気付かない可能性があります。 ただし、この変更により、リソースの動作に大きな違いが生じるため、メジャー バージョンの更新プログラムとして扱うことを決定する場合があります。

また、ワークフローの実行番号をバージョン番号として使用するなど、よりシンプルなバージョン管理戦略を使用する選択も可能です。 この方法は実装が簡単ですが、コードを使用するユーザーにバージョン間の違いを効果的に伝えることができないことを意味します。

バージョンとワークフロー

Azure CLI を使用するなど、対話形式でコードを発行する場合は、発行するときに、テンプレート スペックまたはモジュールに割り当てるバージョン番号を考えることになるでしょう。 ただし、自動化されたデプロイ ワークフローでは、バージョン番号を割り当てるアプローチを変更する必要があります。 ワークフローで、重大な変更を自動的に検出したり、メジャー バージョン番号やマイナー バージョン番号を増やすべきタイミングをアドバイスしたりすることはできません。 テンプレート スペックまたはモジュールを発行する前に、バージョン管理を慎重に検討してください。

1 つの方法は、次の図に示すように、Bicep コードに "メタデータ ファイル" を併せて格納することです。

Diagram that shows a file system hierarchy with two modules and a template spec, each with an associated metadata dot J S O N file.

Bicep コードを更新するたびに、対応するメタデータ ファイルのバージョン情報を更新します。 重大な変更と重大でない変更を正しく識別して、バージョン番号を正しくインクリメントできるようにします。

ヒント

チームがプル要求を使用して Bicep コードをレビューする場合は、コードに対する変更がメジャー バージョン番号やマイナー バージョン番号の変更を要するものかどうかを、レビュー担当者に確認してもらいます。

次の演習では、メタデータ ファイルの使用方法について説明します。

ワークフローの数をいくつにするか

テンプレート スペックとモジュールのコレクションを構築するのが一般的です。 多くの場合、これらを同じ Git リポジトリに保持することは理にかなっています。

GitHub Actions で "パス フィルター" を使用すると、リポジトリ内のモジュールまたはテンプレート スペックごとに個別のワークフローを作成できます。 この方法は、1 つのファイルを変更するたびにリポジトリ内のすべての Bicep ファイルの新しいバージョンを発行しないようにするのに役立ちます。 "再利用可能なワークフロー" を使用して、一元化されたファイルでワークフローの手順を定義できます。これによって各モジュールとテンプレート スペックのワークフローを軽量に保つことができます。

たとえば、前に示したファイル構造と同様のファイル構造があるとします。 Bicep ファイルごとに 1 つずつ、3 つの個別のワークフローを構成できます。 各タブを選択すると、対応するワークフロー定義とそのパス フィルターが表示されます。

name: 'publish-module-1'

on:
  push:
    branches:
      - main
    paths:
      - 'module-1/**'

jobs:
  publish:
    uses: ./.github/workflows/publish-module.yml
    with:
      path: 'module-1/main.bicep'

module-2/main.bicep ファイルのみを変更するとします。 モジュール 2 のワークフローのみが実行されます。 ただし、同じコミット内の複数のファイルを変更すると、それぞれに関連する各ワークフローがトリガーされます。

Note

再利用可能な Bicep ファイルごとにワークフローを作成する方法は、シンプルで柔軟です。 ただし、多数の Bicep ファイルがある場合や、モジュールごと、テンプレート スペックごとの個別のワークフローの保守をしない場合は、面倒になる可能性があります。

変更されたコードを見つけるスクリプトをワークフロー内に記述して、それらのファイルのみを発行することもできます。 これはより複雑なアプローチであり、この Microsoft Learn トレーニング モジュールの範囲を超えています。

再利用可能な Bicep コードの環境

Bicep を使用して Azure にデプロイする場合、運用環境に発行される前に、複数の環境を使用してコードの検証とテストに役立てるのが一般的です。 以前の Microsoft Learn トレーニング モジュールでは、デプロイ ワークフローから複数の環境を操作する方法について説明しました。

組織によっては、Bicep モジュールとテンプレート スペックに対して同じ原則を適用しているところがあります。 たとえば、最初にモジュールの新しいバージョンを非運用レジストリに発行して、各モジュールのユーザーが新しいバージョンを試すことができるようにします。 その後、ユーザーがサインオフした後、モジュールを組織の運用レジストリに発行できます。

通常のデプロイと同様に、"ジョブ" と "再利用可能なワークフロー" を使用して、環境全体のデプロイ順序を定義できます。 この Microsoft Learn トレーニング モジュールでは、ワークフローをシンプルに保つために単一の環境に発行します。

レジストリからモジュールを使用する場合、またはテンプレート スペックを Bicep モジュールとして使用する場合は、"エイリアス" を使用できます。 モジュールを定義するたびにレジストリ名やテンプレート スペックの場所を指定するのではなく、エイリアスを使用します。

エイリアスを使うと、デプロイ プロセスを複数の環境に利用できます。 たとえば、モジュールを定義するときに、レジストリ名の代わりにエイリアスを使用することが考えられます。 その後、デプロイ ワークフローを設計して、次のレジストリにマップするエイリアスを構成できます。

  • サンドボックス環境にデプロイする場合の開発モジュール レジストリ。
  • 他の環境にデプロイする場合の運用レジストリ。

Note

エイリアスは発行時には適用されません。 Bicep ファイル内でテンプレート スペックまたはモジュールを使用する場合にのみ機能します。