はじめに
この記事は、Gitflowをベースとした開発フローで、リリースブランチの運用に、「リリース管理台帳」というExcelシートを活用した、私自身の経験をご紹介するものです。
Gitによる開発では、Gitflow、GitHub Flow、Git Feature Flow、GitLab Flow など、様々なブランチ戦略が提唱されています。それぞれ、メリット・デメリットがあり、「これがベスト」と言えるものはありません。プロジェクトの規模やリリース頻度によって、適合しているブランチ戦略を選択すればよいです。
この記事は、Gitflowが適合するプロジェクトを対象としています。そのプロジェクトとは、以下のようなものです。
- プロジェクト内に開発者が数十名いて、複数の機能の開発が並行して行われている。
- リリース計画に基づいて、月に数回（多くても週１回程度）のリリースが行われる。
- 複数の機能が同時にリリースされることもある。
開発者が数十名になると、それぞれの担当者が、developブランチやfeatureブランチで開発することになります。そのリリースが月に数回行われる場合、１回のリリースで、複数の機能やバグフィックスなどが同時にリリースされることになります。
複数のdevelopブランチ、featureブランチをテストする際に、テスト用のサーバーが１台のみだとすると、複数のブランチを１つにまとめて、テスト用サーバーにデプロイすることになります。
この、１つにまとめるブランチとして、releaseブランチを使用します。releaseブランチを使うことのメリットは、それがうまく動かなかった場合、そのブランチを捨てて、別のreleaseブランチを作ることができるという点です。もし、releaseブランチを使わずに、いきなりmainブランチにマージする運用だと、それがうまくいかなかった際に、元に戻すのは大変です。
Gitflowについての参考記事：
https://qiita.com/jun1s/items/e45761f103c52926d5e5
リリース管理台帳
私が以前参画していたプロジェクトでは、releaseブランチは、release_202504_01 などの名前を付けるようにしました。202504が年月で、01はその月の中での連番です。リリースブランチを作成する時点では、リリース日が未定の場合が多いので、年月のみをブランチ名に入れます。
バグフィックスなど、緊急リリース用の hotfixブランチも、hotfix_202504_01などの名前を付けるようにしました。
また、「リリース管理台帳」というExcelファイルで、リリースを管理するようにしました。
その中で、「release_202504_02」、「hotfix_202504_01」など、リリースする単位でシートを分けました。
各シートに、そのリリースブランチに含まれるチケットとプルリクエストを一覧にしました。
「リリース管理台帳」は、SharePointやGoogleドライブなどの共有サーバーに置いて、各開発者が自身の担当分を記入します。
実際のリリース管理台帳は、次のようなイメージになります。
次のURLで、リリース管理台帳のサンプルファイルをダウンロードできるようにしました。zipファイルの中に、日本語版の「リリース管理台帳.xlsx」と、英語版の「ReleaseTracker.xlsx」が入っています。よろしければ、お使いください。
https://mnitta220.github.io/downloads/ReleaseTracker.zip
シート内の各項目は、ほぼ説明不要かと思いますが、２点だけ説明させていただきます。「リポジトリ」は、プロジェクトが複数のリポジトリに分かれている場合に使用します。リポジトリが１つのみの場合は、この項目は不要なので削除してください。また、「担当者」は開発を行った担当者ではなく、各自の開発ブランチをリリースブランチにマージするプルリクエストを作成した担当者です。
運用フロー
以下、リリース管理台帳を用いた運用のフローをご説明します。以下の説明では、「releaseブランチ」と「hotfixブランチ」を併せて、「リリースブランチ」と記述します。また、「mainブランチ」または「masterブランチ」を「mainブランチ」と記述します。
基本フロー
- リリース計画が立てられたら、リリース管理台帳の「template」シートをコピーして、リリースブランチ名のシートを作成する。「リリース(予定)日」を入力する。作成したことをプロジェクト内に周知する。
- 各developブランチまたはfeatureブランチの開発者は、自身の担当ブランチをそのリリースに含めたい場合、リリース管理台帳に必要事項を記入する。（ここに記入するのは、リリースブランチへのマージを行うブランチのみ。developブランチにマージするfeatureブランチなどは記入しない。）
- 各developブランチまたはfeatureブランチの開発者は、自身の担当ブランチの開発が進んで、リリースブランチにマージできる段階になったら、リリースブランチにマージする。そのリポジトリで、まだリリースブランチが作成されていなければ、最新のmainブランチからリリースブランチを作成して、リポジトリにpushしてからマージする。
- リリースブランチをテストできる段階になったら、リリースブランチをテスト環境にデプロイしてテストを行う。
- テストが完了して、リリースできることが確認できたら、リリース実施日に、リリースブランチを本番環境にデプロイする。
- 本番環境で正常に動作していることが確認できたら、リリースブランチをmainブランチにマージする。mainブランチにタグを付ける。（mainブランチは、常に本番環境にデプロイされているソースコードと同じ状態を維持する。）
- mainブランチを、他のリリースブランチ、developブランチ、featureブランチにマージする。（これを行わないと、次回のリリース時にデグレが発生することになる。またコンフリクトの解消で苦労することになる。）
例外フロー
- リリースブランチの中の１つの機能にバグが見つかったり、開発が遅れるなどして、リリースから外すことになり、リバートもむずかしい場合は、そのリリースブランチを捨てて、
release_202504_01aなどの別の名前でリリースブランチを作成する。（このためにも、リリース管理台帳の各リリースブランチのシートで、何が入っているかを管理することが大事となる。また、リリースに入れられることがほぼ確実になるまでは、各developブランチ、featureブランチをリリースブランチにマージしないようにする。）
リリースが増えてくると、リリース管理台帳のシート数が増えてきます。ほぼ参照されなくなった過去のリリース分は、別のファイル名でバックアップするなどして、リリース管理台帳を軽い状態に保つのがよいと思います。
最後に
上記の運用は、私が以前参画していたプロジェクトで、ブランチ運用が破綻していたのを立て直すために、私が提案して、それが採用されて、正常に運用されるようになった経験に基づいています。
実際に運用すると、複数のリリースブランチが同時に存在した状態になり、リリースの順番が当初の予定と逆になったりするなど、様々な事態が発生しましたが、大きな混乱なく、運用できるようになりました。
開発者にとっては、リリース管理台帳を記入しなければならないことは、やや手間ではありますが、ブランチ運用が改善するのであれば、これくらいの手間は受け入れてもよいのではないでしょうか？
リリース管理台帳を運用すると、それぞれのリリースに何が入っているのかが明確になるので、プロジェクト全体で、リリース内容の見える化と情報共有が進むという利点もあります。
最初にも書いた通り、上記の運用は、月に数回（多くても週１回程度）のリリースが行われるプロジェクトに向いています。毎日リリースが行われるようなプロジェクトでは、releaseブランチとリリース管理台帳による運用は大変なので、やらない方がよいと思います。