技術メモ

技術メモ

ラフなメモ

並行開発/運用のためのブランチモデルを整理する

Git

GitFlowをベースにしたリリース時期が異なる複数バージョンの並行開発に耐えうるGitFlowを検討しています。まずは標準的なGitFlowの役割を整理した上で、並行開発に耐えうるブランチモデルを検討することにします。

GitFlow

GitFlow はVincent Driessenによって提唱されたGitを用いたブランチモデルです。

ポイント

[6]によると、GitFlowのポイントとして以下のようなものがあります。

  • 並列開発が容易
  • 機能開発を複数人で共有して開発しやすい
  • developブランチを用いたリリースフロー
  • hotfixブランチを用いた緊急修正のサポート

GitFlowの各ブランチの役割

GitFlowではいくつかの役割を持つブランチがあります。

  • master
  • develop
  • hotfixes
  • release branches
  • feature branches

f:id:tutuz:20190609211501p:plain

各ブランチの役割について簡単におさらいしておきます。

master

プロダクトとして常にリリース可能なブランチ。リリースするときにタグ付けをする。

develop

開発ブランチ。次のリリースのための最新の開発ブランチ。developブランチのソースコードが安定し、リリース準備ができたときにdevelopブランチの変更内容をmasterブランチへマージすることになる。

feature branches

機能ブランチ。次のリリースないしは新しい機能の開発のためのブランチ。developブランチから作成される。最終的にはdevelopブランチへマージされるか、捨てられるかのいずれかになる。ブランチ名の慣習としては、master, develop, release-*, hotfix-* 以外なら全てOKである。

release branches

リリースブランチは、プロダクトリリースのためのブランチです。リリース準備ができたdevelopブランチから作成します。新しい機能開発やバグフィックスができたタイミングで作成されます。masterブランチにタグ付けでマージされ、またdevelopブランチにマージされます。

hotfixes

リリースされているプロダクトで緊急を要すバグがあった場合に対応するためのブランチです。masterから作成されます。masterへマージする際にタグ付けするバージョン番号を増加させます。developブランチへもマージします。

検討ポイント

GitFlowにおいてmasterブランチは常にリリース可能なプロダクトの最新の状態になっています。常に最新の1つのプロダクトをサポートする場合、GitFlowは十分強力なブランチモデルと言えます。しかし、複数バージョンで並行開発する場合、ひとつのmasterで開発するブランチモデルでは十分に機能しないでしょう。

ある本番環境で動作するプロダクトはもちろんひとつのバージョンのみですが、本番環境は1つではなく、複数の環境に存在することを仮定します。そして、環境ごとに複数のバージョンのプロダクトを開発/リリースする必要があります。

複数のバージョンをサポートする必要があるプロダクトの並行開発には上記のGitFlowをそのまま適応することはできません。

そこでsupport/ltsブランチのコンセプトについて考えてみます。

support/lts

参考[3]を見ると、複数のメジャーバージョンのプロダクトをメンテナンスする場合はsupportブランチが不可欠とあります。

f:id:tutuz:20190609231610p:plain

supportブランチはmasterのあるtagから作成されます。hotfixブランチがsupportブランチから作成され、必要な修正を加えた後supportブランチにマージします。supportブランチに付与されているtagのバージョン番号を増加させます。その後修正用のhotfixブランチは削除します。参考[9]ではltsブランチ

lts: long term support releases, also production-ready

と命名していますが、意味としてはsupportブランチと同義でしょう。ltsという名称のほうがsupportブランチよりも意味がわかりやすいかもしれません。

ltsブランチのコンセプトはいろいろなプロダクトで用いられており、例えば[11]のAzure IoT SDKの例や[13]のRuby on Railsの例を見ることができます。Azure IoT SDKの例では[12]のように、以下のようにlts branchの運用が示されています。

Schedule1

Below is a table showing the mapping of the LTS branches to the packages released

Maven Package Github Branch LTS Status LTS Start Date Maintenance End Date Removed Date
LTS_01_2018_Rev01

2018-02-9 		lts_01_2018 Active 2018-02-09 2018-06-30 > 2018-12-31
2017-07-24 lts_07_2017 Deprecated 2017-07-01 > 2017-12-31 2018-06-30
  • 1 All scheduled dates are subject to change by the Azure IoT SDK team.

Planned Release Schedule

f:id:tutuz:20190610002458p:plain

lts-release

[15]の例では、ltsブランチのリリースのためにlts-releaseブランチのコンセプトを導入しています。

まとめ

過去バージョンのプロダクトへのサポート/開発を最新バージョンのプロダクトと並行して実施する場合にはlts(support)ブランチの運用が有効そうです。ltsブランチのメンテナンスをどのようなブランチモデルで実施するかはもう少し調査する必要があります。

たとえばltsブランチのリリースのためにlts-releaseブランチを作成する、ltsブランチの修正のためにlts-developブランチ、lts-featureブランチを作成するなどといった運用方法が考えられます。

またブランチ名については、lts という名前ではなく、x-y-stable / 2018-01 などといった名称が考えられそうです。

参考

  1. https://nvie.com/posts/a-successful-git-branching-model/
  2. https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
  3. https://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches
  4. http://keijinsonyaban.blogspot.com/2010/10/a-successful-git-branching-model.html
  5. https://moznion.hatenadiary.com/entry/2017/01/07/135331
  6. https://datasift.github.io/gitflow/IntroducingGitFlow.html
  7. https://havelog.ayumusato.com/develop/git/e513-git_branch_model.html#e513-3-1
  8. https://dev.classmethod.jp/tool/git/cmstudy-git-flow/
  9. https://contao.org/en/news/git-branch-strategy.html
  10. https://www.contaocms.jp/news-and-teamblog/git-support-zweige-fuer-lts-versionen.html
  11. https://blogs.technet.microsoft.com/jpitpro/2018/02/15/iot-sdk-lts-branch/
  12. https://github.com/Azure/azure-iot-sdk-java
  13. https://github.com/rails/rails
  14. https://linuxcontainers.org/ja/lxd/getting-started-cli/
  15. https://wiki.qt.io/Branch_Guidelines
  16. https://stackoverflow.com/questions/39978200/long-term-support-branches-in-git