@takamii228知は力なり2019-11-26master中心のブランチ戦略で開発している話ここ数年、CI/CDパイプラインを構築したりブランチ戦略を考えるロールで仕事をすることが多いのですが、ブランチ戦略はいつも頭を悩ませていました。Flowの採用を考えたりしたのですが、ブランチやマージの戦略がちょっと重厚でめんどうなだという印象を持っていました。「releaseブランチとかpre-productionとか管理面倒だからぶっちゃけmasterだけでよくね?」とふと思い、master中心のシンプルなブランチ戦略を考え、実践してみました。するとそれなりにうまく立ち回ることができるようになっていたので、整理もかねてまとめておきます。対象とするプロジェクト本ブランチ戦略は、以下のような開発チームに対してうまく機能できると考えています(※もちろんこの方法が最適な解とは限りません)バックエンド・フロントエンド・スマホアプリなど開発領域ごとにチームが別れているサービスを成立させるためには各チームが独立にリリースすることはできず、最終的には資材の同期を取る必要がある先に開発を終えたチームは次の案件の開発に着手しており、追加開発とリリース用の2つの資材を管理する必要がある開発チームメンバーは数人から20人程度masterをcleanに保つためのCIが整っている基本的な考え方master中心のブランチ戦略のベースとなる考え方は以下の通りです。Flow)を表すブランチはどこかのブランチにマージするか、マージしない場合は独立に更新を続け最終的には捨てるこの機能を入れる資材と入れない資材が必要、というときにブランチを切って開発の流れを分岐させるリリースバージョンはタグに紐づけるようにし、ブランチと実行環境は紐付けないこれら原則に従うことで、以下のようなメリットが得られます。Requestのマージ先はhotfix以外はすべてmasterになり、追加開発時のマージ先誤りの事故を防ぐことができるブランチと実行環境が分離されるため、環境管理とは独立して資材のバージョン管理ができる以下、実際にリリースの前・リリース後のブランチ戦略を説明していきます。リリース前のブランチ戦略リリース前のブランチ戦略は非常にシンプルです。masterブランチに対して、featureブランチ・bugfixブランチをマージすることで機能追加を反映していきます。初期開発時に利用するブランチは以下の通りです。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。テスト・QA等で発覚したバグの修正用のブランチ。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。このとき、成長するブランチはmasterブランチのみであり、チームメンバはmasterブランチのみを追いかけていればよいです。検証環境へのリリース資材を作成する場合はtagでバージョンとコミットハッシュを紐付けることでバージョン管理ができます(図のv0.1.0、v0.1.1)。リリース後のブランチ戦略ここでのリリース後、とは自分のチームの開発範囲のリリースを指します。バックエンドチームであればバックエンドのAPIのみのリリースを指します。バックエンドは順調に開発が進み先に環境へリリースできた一方で、フロントエンドは画面の仕様調整に難航しスケジュールが遅れてしまった、というケースはよくあると思います(逆もしかり)。このときバックエンドチームはフロントエンドチームの待ちの状態になるため、開発チームの余ったリソースを使って先に追加開発に着手し始めるケースがよくあります。このとき、masterブランチのみの運用だと本来のリリースには含めてはいけない資材が混じってしまう可能性があるため、フロントエンドの改修がバックエンドに波及したときのhotfixの対応を受け入れるために、masterとは別のproductionブランチを作成し2つの流れを作って運用します。productionブランチを作っておくことで、フロントエンドチームと同期をとったときの不具合のフローと追加開発のフローを分けて管理することができます(下図)。利用するブランチは以下の通りです。リリース後のブランチはリリース前にあったブランチに加えてproductionブランチとhotfixブランチが追加されています。最新のリリース版、リリースごとに作成する。リリース版にのみ緊急に反映させたいパッチがあればあてる。追加開発版のリリースが行われたら今まで使っていたproductionブランチは削除し、リリース対象のタグから新しいproductionブランチを作成する。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。テスト・QA等で発覚したバグの修正用のブランチ。CIが通ったもののみマージする。チケット番号と紐付ける。masterにマージしたら削除する。リリース版バグ修正用のブランチ。CIが通ったもののみマージする。チケット番号と紐付ける。productionにのみパッチをあてる場合はproductionから切ってproductionにマージし削除する。master両方に必要なパッチの場合はそれぞれの根本から2本パッチを充ててそれぞれにマージし削除する。productionブランチは外部チームへの提供可能なバージョンのタグを切ったときに作成します。productionブランチにはリリースに必要なパッチや緊急のhotfixのみの変更が当てられます。hotfixのパッチは場合によってはデグレを防ぐためにmasterとproduction両方に当てる必要があります(※後述)。追加開発向けの機能追加はリリース前と同様です。リリース版で発覚したバグ修正のhotfixは、追加開発を行っている最新版のmasterに入れる場合と入れない場合とで以下のように対応を分けます。リリース版および最新版にもパッチを入れる場合(例:恒久的なバグ対応)hotfixブランチをproductionから切って、productionにマージするhotfixブランチをmasterからも切って、productionブランチへのhotfixと同様の変更を加えmasterにマージする(cherry-pickなどを使う)リリース版のみに入れるパッチの場合(例:ライブラリの緊急パッチ等の暫定対処)hotfixブランチをproductionから切って、productionにのみマージするhotfixの対応は一見複雑そうに見えますが、「masterが常に追加開発の最新版である」こと、「productionブランチがリリース版の最新版である」ことを考えると意外とシンプルにまとまっているのではないでしょうか。productionブランチはmasterには不要な変更を含んでいる場合があるため、masterにはマージしません。次のリリース版のtagが打たれたらまた新しいproductionブランチを作成します。Flow等がありますが、どちらも扱うブランチの種類が多かったりデプロイ先の環境と密結合に語られていて扱いにくい印象を持っていました。「masterを最新の安定版ブランチ」とする、というこのmaster中心のブランチ戦略を使うことで、シンプルで運用しやすい資材管理ができるようになったと個人的には考えています。興味を持たれた方はぜひ実践してみてください。21:49master中心のブランチ戦略で開発している話Tweet広告を非表示にする関連記事2019-12-312019年の振り返り的な何か今年もざっくり振り返ろうと思う。2018年の記事はこちら。検索はてなブログをはじめよう!takamii228さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。