GitFeatureFlow風ブランチ運用がうまくハマって、少しずつズレてきた。そんなブランチ運用の話
こんにちは。Showcase Gigでバックエンドエンジニアをやっている カピバラ です。最近本名で呼ばれなくなってきました。
今回は、弊社プロダクトである O:der Table のバックエンド開発のブランチフローの話をします。 対象読者は社内のエンジニアですが、せっかくなのでテックブログにします。
ブランチ運用を振り返ります
O:der Table の開発をもともとGitFlowでやってきたところ、1年前くらいにGitFeatureFlow（風）ブランチ運用を導入しました。 なかなかよい感じに運用できてきたのですが、最近社内でちらほらと課題感も耳にします。
運用1周年のよいタイミングかなと思い、そのあたりの経緯について書きます。
GitFlow
1年前くらいまではこのブランチフローに従って開発を進めていました。
ご存じGitFlowです。「とりあえずこれ」みたいな感じで利用されることも多いのではないでしょうか。 よいですよね、私も好きです。
加えて弊社では、developブランチへのマージで自動的にdevelop環境へデプロイされるようになっておりました。
当時の課題感
GitFlowを使っていた当時、社内では3チーム体制でO:der Tableの開発を進めていました。 その中の1チームは比較的大型の機能開発を進めており、developブランチにマージされることなく3ヵ月が経過した、超巨大featureブランチを抱えていました。そんなブランチを抱えている状況下では、次のような問題がありました。
・developブランチをfeatureブランチにマージしたらえらいコンフリクトした。つらい。
・頑張ってコンフリクト解消したけど動かない。動かない原因はマージミスなのかマージ元のコードのせいなのかわからない。つらい。
・develop環境で動作確認したいけど、developにマージするとリリース対象になってしまうので、確認したらちゃんとrevertしないといけない。つらい。
つらいですよね。
課題感さらに深堀り
問題点についてさらに深掘りしてみました。
developブランチをfeatureブランチにマージしたらえらいコンフリクトした。つらい。
えらいコンフリクトする→長いこと他チームの開発内容を取り込めていない→取り込むタイミングが決まっていないので、「余裕ある時にやろう」となる。結果、余裕なんてないので取り込めない。
頑張ってコンフリクト解消したけど動かない。動かない原因はマージミスなのかマージ元のコードのせいなのかわからない。つらい。
コンフリクト解消したけど動かない→マージ元・先、どちらも不安定な開発中のブランチですので、どちらが原因とも考えられる。
develop環境で動作確認したいけど、developにマージするとリリース対象になってしまうので、確認したらちゃんとrevertしないといけない。つらい。
カジュアルにdevelop環境にデプロイして動作確認したい。
ということで、「同時並行で開発している他チームの開発内容を取り込むタイミングが難しい」、「開発環境での確認がしにくい」といった課題感が見えてきました。
そこでGitFeatureFlow
それからいくつかブランチフローを吟味したのですが、 GitFeatureFlow がマッチしそうだな、と考え導入しました。決め手としては、元の記事で書かれている以下のポイントでした。
大小どんな規模の案件や緊急リリースが混在していても、featureブランチが独立しているため、他のブランチとのリリース日を気にする必要がない
オリジナルのGitFeatureFlowと異なる点は以下です。
・作業ブランチ名はfeatureブランチではなくreleaseブランチ
・各releaseブランチからfeatureブランチを切って作業して、feature -> releaseブランチのマージ時にチーム内レビューをする
以下のような運用イメージです。
合わせて、以下の運用ルールも定めました。
・masterブランチにマージされたものは速やかにreleaseブランチに取り込むこと
・developブランチは自由にマージ&デプロイ可能。壊れたらサクッと git reset --hard origin/master しよう
意図としては、もともとの課題感を受けて「こまめにマージするタイミングを明確化」したことと、「マージ元はプロダクションリリースされたものだから安定している」はず。それを取り込んで壊れたら、それはマージミスの可能性が高いよね...という判断ができることでした。また、developブランチを使い捨てとして、気軽なデプロイができるようにしました。
本来のGitFeatureFlowに比べてやや複雑にはなってしまったものの、結果的に、そこそこ課題感は解消できたかなと思っています。 複数チームで同一のリポジトリで開発する場合に、このルールはうまくはまっていたように思えました。
ちょっとずつずれてきたかも
そんな運用を一年くらい続けていますが、時間がたてばチームも変わります。プロダクトの開発体制も変わっていきます。現在の運用の煩わしさが目立つことも増えてきました。
まず大きいのは、以下の2点です。（これは極めてポジティブな変化です）
・プロダクトのリリースフローが確立された
・「ビックバンリリースを避けて、こまめにリリースしていこう」という意識が社内に広まった
結果的に現在では、複数のリリースブランチが必要とされることはなくなりました。
さらに、少人数のチームでしか扱わないリポジトリであれば、develop環境へのデプロイの際にわざわざdevelopブランチマージを挟むのも煩わしいです。（弊社はtagを指定してデプロイできるしくみが整備されているので、作業中のブランチをサクッとデプロイした方が早い）
ということで、チーム（リポジトリ）によってはGitFlowに戻ったりしています。
まとめ
ブランチ戦略に「これがベスト」なんてものは存在しません。
チームやプロダクト、あるいはそのほかさまざまな要素を加味して検討して、その時のベストを探ることが一番ですね。
何ごとについてもそうですが、常に振り返って改善点を提案、試行していく ことが大事だなーと実感しています。
この記事が気に入ったらサポートをしてみませんか？