ブランチについて

8 分

Bicep テンプレートを作成し、Git レポジトリ内で作業すると、最終的にチームの変更はすべてリポジトリのメインブランにマージされます。不要な変更が運用環境にデプロイされないように、メインブランチを保護することが重要です。ただし、共同作成者が柔軟に作業し、チームとコラボレーションし、アイデアを簡単に試すことができるようにする必要もあります。

このユニットでは、ブランチ戦略と、メインブランチを保護する方法について学習します。また、ブランチのレビュープロセスを設定する方法についても学習します。

メインブランチの保護が必要な理由

メインブランチは、Azure 環境にデプロイされる機能について信頼できる情報源です。多くのソリューションでは、"開発"、"品質保証 (QA)"、"運用" など、複数の環境が必要です。他のシナリオでは、運用環境のみを使用する場合もあります。使用する環境の数に関係なく、メインブランチがチームメンバーのコントリビューション先となるブランチです。メンバーによる変更は、最終的にメインブランチに表示されます。

考えられる一般的なプロセスは、次のとおりです。

チームメンバーは、共有されているリポジトリを複製します。
メンバーは、ローカルにコピーした自分専用のリポジトリ内のブランチでローカルの変更を行います。
メンバーは、変更が完了すると、それらの変更をローカルリポジトリのメインブランチにマージします。
メンバーは、それらの変更をリモートリポジトリのメインブランチにプッシュします。
一部のシナリオでは、リモートリポジトリへのプッシュによって、自動化されたパイプラインがトリガーされ、コードの検証、テスト、デプロイが行われます。パイプラインについては、他の Microsoft Learn モジュールを参照してください。

このプロセスを説明する図を次に示します。

ローカル変更を行い、変更をリモートのメインブランチにプッシュし、パイプラインをトリガーするプロセスを示す図。

チームメンバーが行った変更によって微妙なバグが発生したとしましょう。プロセスが完全に実行された後、そのバグはプロジェクトの main ブランチに存在するようになり、運用環境にデプロイされています。バグは、ブランチをデプロイしてエラーが発生するまで検出されない可能性があります。あるいは、バグの種類によっては、デプロイは成功しても、後の小さな問題の原因となる可能性があります。

別のシナリオとして、あるチームメンバーが 1 つの機能の作業を行っており、その機能に関して完了した作業の半分を共有リポジトリのメインブランチにプッシュするとしましょう。 main ブランチに対して加えようとしている変更は、未完成で、テストもまだ行っていません。これらの変更は、おそらく、運用環境にデプロイすべきではありません。機能が完成するまで、運用環境へのデプロイをブロックする必要があります。新しく完成した機能がメインブランチ上にある場合は、顧客にデプロイできないことがあります。

ヒント

これらの問題は、複数の人が同じコードにコントリビューションを行う大規模なチームでは特に困難なものとなりますが、このモジュールのガイダンスは、複数の人と共同作業をする際にはいつでも役に立ちます。このガイダンスは、プロジェクトで作業しているのがあなただけで、同時に複数の機能に取り組んでいるという場合でも役立ちます。

より優れた作業方法は、作業している間、変更を個別に保持することです。その後、チームの共有リポジトリのメインブランチにマージする前に、別のチームメンバーに変更をレビューしてもらうことができます。このプロセスは、変更のマージを承認する前に、変更についてチームが情報に基づいた決定を行うのに役立ちます。

機能ブランチ

"機能ブランチ" は、開始しようとしている新しい作業を示します。その作業内容は、Bicep ファイルで定義されたリソースに対する構成の変更であったり、デプロイする必要がある新しいリソースセットであるかもしれません。新しい作業を開始するたびに、新しい機能ブランチを作成します。

機能ブランチは、メインブランチから作成します。ブランチを作成すれば、確実に Azure 環境の現在の状態から始めることができます。次に、必要なすべての変更を行います。

コード変更はすべて機能ブランチにコミットされるため、リポジトリのメインブランチには干渉しません。チームの他のメンバーが、メインブランチを緊急に変更する必要がある場合、そのメンバーは、あなたのブランチとは関係ない別の機能ブランチで変更を行うことができます。

機能ブランチで共同作業を行うこともできます。機能ブランチを発行して共有リポジトリにプッシュすることにより、自分とチームメンバーは変更について共同で作業できます。また、あなたが休暇に入る場合は、機能を他の誰かに渡して完了してもらうこともできます。

機能ブランチを更新する

自分の機能ブランチが進行中に、リポジトリのメインブランチに他の機能がマージされるかもしれません。その結果、自分の機能ブランチとプロジェクトのメインブランチに差異が生じることになります。この差異が大きくなるほど、後で 2 つのブランチを再びマージするのが難しくなり、さらに多くのマージ競合が発生する可能性があります。

リポジトリのメインブランチに加えられたすべての変更を取り入れることができるように、機能ブランチを定期的に更新する必要があります。また、機能ブランチをメインブランチにマージする前に、機能ブランチを更新することをお勧めします。こうすることで、新しい変更をメインブランチに簡単にマージできるようになります。

ヒント

メインブランチを機能ブランチに頻繁にマージしてください。

小規模で有効期間の短いブランチを使用する

機能ブランチの有効期間を短くすることを目指してください。このアプローチは、ブランチが同期していない時間を減らすことで、マージの競合の回避に役立ちます。また、このアプローチを使用すると、自分が行った変更を同僚が簡単に理解できるようになります。これは、誰かに変更内容をレビューしてもらう必要がある場合に役に立ちます。

大規模な作業を小さい作業に分割し、その作業ごとに機能ブランチを作成します。機能が大規模になる程、誰かがその作業を行う時間は長くなり、機能ブランチの存在時間も長くなります。各機能ブランチをマージするたびに小さな変更を運用環境にデプロイしながら、より大きな作業を徐々に完成することができます。

一連の Bicep コードにいくつかの変更を加えようとしているとします。いくつかのリソース定義をモジュールに移動します。また、いくつかの新しいリソースを Bicep ファイルに追加する必要もあります。最初に、専用のブランチで、すべてのモジュールのリファクタリングを行うことをお勧めします。モジュールがマージされたら、Bicep ファイルへの追加作業を開始できます。変更を分割することによって、各変更 (およびそのブランチ) は小規模になって、理解しやすくなります。

この方法で作業を行う場合、if キーワードを使用して、準備ができるまでリソースのデプロイを無効にすることが便利です。次のコード例は、if キーワードを使って、ストレージアカウントを定義するが、すべての変更が完了するまでストレージアカウントのデプロイは無効にする Bicep ファイルを作成する方法を示しています。

@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false

resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = if (storageAccountReady) {
  name: storageAccountName
  location: location
  kind: 'StorageV2'
  sku: {
    name: 'Premium_LRS'
  }
}

パラメーターを使用して、さまざまな環境で storageAccountReady 変数に異なる値を指定できます。たとえば、テスト環境ではパラメーター値を true に設定し、運用環境では false に設定できます。そうすることで、テスト環境で新しいストレージアカウントを試すことができます。

Note

運用環境でこの機能を有効にするときは、変更を有効にするために、次の手順を実行する必要があることを忘れないでください。

パラメーター値を変更する。
Bicep ファイルを再デプロイする。

機能ブランチのマージ

機能ブランチでの作業が完了したら、それをリポジトリのメインブランチにマージする必要があります。マージする前に、機能ブランチに加えられた変更をレビューすることをお勧めします。 pull request を使用すると、コードをレビューできます。 pull request の詳細については、このモジュールで後ほど詳しく学習します。

ブランチ保護

GitHub では、共有リポジトリのメインブランチの "ブランチ保護" を構成できます。ブランチ保護では、次のようなルールを適用します。

pull request を使用する場合を除いて、変更をメインブランチにマージすることはできない。
変更は、少なくとも 2 名の他者によってレビューされる必要がある。

保護されたブランチに他のユーザーがコミットを直接プッシュしようとすると、そのプッシュは失敗します。次のユニットでは、ブランチ保護を適用する方法について学習します。

ブランチポリシー

Azure DevOps では、共有リポジトリのメインブランチの "ブランチポリシー" を構成できます。ブランチポリシーでは、次のようなルールを適用します。

pull request を使用する場合を除いて、変更をメインブランチにマージすることはできない。
変更は、少なくとも 2 名の他者によってレビューされる必要がある。

保護されたブランチに他のユーザーがコミットを直接プッシュしようとすると、そのプッシュは失敗します。次のユニットでは、ブランチポリシーを適用する方法について学習します。

その他のブランチ戦略

Bicep コードで共同作業を行う場合、さまざまなブランチ戦略を使用できます。各ブランチ戦略に利点と欠点があります。

これまでに学習したプロセスは、"トランクベースの開発" 戦略の 1 つのバージョンです。このブランチ戦略では、作業は有効期間の短い機能ブランチで行われ、その後、単一のメインブランチにマージされます。変更がマージされるたびに、共有リポジトリのメインブランチの内容を運用環境に自動的にデプロイしたり、変更をまとめ、スケジュール (たとえば、週に 1 回) に従ってそれらをリリースしたりすることができます。トランクベースの開発は理解しやすく、オーバーヘッドをあまりかけずにコラボレーションを行うことができます。

一部のチームでは、完了した作業を、運用環境にデプロイした作業と分離しています。有効期間の長い "開発" ブランチを、機能ブランチのマージ先として使用します。変更を運用環境にリリースするときに、"開発" ブランチを "メイン" ブランチにマージします。

他のブランチ戦略の中には、"リリースブランチ" の作成を必要とするものもあります。一連の変更を運用環境にデプロイする準備ができたら、デプロイする変更を含むリリースブランチを作成します。これらの戦略は、Azure インフラストラクチャを定期的にデプロイする場合、または変更を他の多くのチームと統合する場合に役立ちます。

他のブランチ戦略としては、Gitflow、GitHub フロー、GitLab フローなどがあります。一部のチームでは、GitHub フローまたは GitLab フローを使っています。これらを使うと、作業を別のチームから分離したり、緊急のバグ修正を他の変更から分離したりすることができるためです。これらのプロセスを使用すると、コミットをソリューションのさまざまなリリースに分割することもできます。これは "チェリーピッキング" と呼ばれます。ただし、変更が相互に互換性があることを保証するために、より多くの管理が必要になります。このモジュールの「まとめ」セクションでは、これらのブランチ戦略の詳細についてのリンクを提供します。

チームに適したブランチ戦略は、チームの作業方法、コラボレーション方法、変更のリリース方法によって異なります。トランクベースの開発などの簡単なプロセスから開始することをお勧めします。このプロセスを使用してチームが効率的に作業できないことが判明した場合は、徐々に他の階層のブランチを導入したり、ブランチ戦略を採用します。ただし、ブランチを追加すればする程、リポジトリの管理が複雑になることは念頭に置いてください。

ヒント

使用するブランチ戦略に関係なく、ブランチポリシーを使用してメインブランチを保護し、pull request を使用して変更をレビューすることをお勧めします。他のブランチ戦略では、保護する必要がある重要なブランチも導入されます。

このモジュールでは、使いやすさのため、機能ブランチを使用したトランクベースの開発を使います。