こんにちは。てぃろです。
今回はブランチ戦略についてソフトウェア品質の側面から考えてみたいと思います。
これまで様々な開発現場を経験してきましたが、どの現場でも全く同じブランチ戦略が取られていることはありませんでした。自分が主導する場合でも「毎回これで行けば問題ない」というような方法はなく、その現場の事情に合わせていつもカスタマイズしていたのが実情でした。
そんな経験則から、どのようにブランチ戦略を考えていけばよいかについて私なりの解釈をご紹介したいと思います。
ブランチ戦略が関わる5つの事情
私の経験則ですが、ブランチ戦略を考えようとしたときに、以下のような事情がいつも関わってきていたのではないかと思います。
- リリース頻度の安定性
- 開発速度
- 開発体制（チームの分け方）
- 開発環境の数
- 品質（障害発生数）
ここからはこれらの事情についてどんなことがあったか少し解説します。
リリース頻度の安定性
まず、リリース頻度の安定性についてですが、ここではリリース頻度は週１が安定的だ、というような単純な話ではありません。
リリース対象となる環境やリリースの順番が直前で入れ子構造になるようなことが必要とされていないか？、と言う話です。そういった状況は安定的なリリースができているとは言えないと思います。
例を出すと長くなるので割愛しますが、とにかくこのような例ではマージ作業が途中でわけがわからなくなることで、デグレが発生したりリリース漏れが出たりして障害の温床になります。マージそのものも大変なので、エンジニアが疲弊してしまうことも大きなマイナスになります。
開発速度
開発速度とは、チームでどの程度の開発物をどの程度の速さで作れているかということを言っています。スクラム開発などでいうベロシティと似たような話です。
この速度が速いと大して問題がないのですが、１つのブランチをずーっと抱え続けて開発が終わらず、いざマージしようとしたら別の修正が大量に入っていてマージが大変！みたいなことが起こることは想像に難くないと思います。もしかしたら、誰しも一度は経験があるかもしれないですよね。
これはタスクの分解の仕方が悪いからだろ？という人もいると思いますし、私もそれはあると思います。ただ、タスクによってはやはりそれ以上分解しきれない重く大きなタスクもあると思うので、一概にはそういうことは言えないかな、と思って開発速度という言い方にしています。
開発体制（チームの分け方）
現在よく採用されているマイクロサービスでは起こりがちな話だと思いますが、多くのチームが単一のリポジトリを同時に修正するパターンがあると思います。
そんなケースは避けようがない部分もあり、マイクロサービス化する中では必ずどんなチームでも一度は頭を悩ませることになるのではないでしょうか。
一番想像しやすいのは、複数チームで同時に修正をしてコンフリクトを大量に起こしてしまう、といったことだと思います。そうなると何が正しいかわかりにくくなりますし、テストすべてやり直しになるなど追加工数が大量に発生してしまうという恐れがあるわけです。
開発環境の数
クラウドが当たり前になって10年ほどになり、開発環境を複数たてていくのがオンプレのときほど苦ではなくなりました。しかし、開発環境を安定的に立て続けるという作業は意外と難しいです。
インフラはアプリケーションに比べれば変更が加えられることは少ないですが、それでも変更点はあります。クラウド利用であれば直接的にコストがかかるところだし、クラウドのリソース利用制限に引っ掛かることもあります。IaCで自動化できると言ってもその自動化までもっていくにはエンジニアの工数が必要になります。何か修正をしたりクラウドサービスがアップデートしたりするなど少しの違いで環境が立ち上がらなくなるなんてのはよくあることです。
これらの事情を踏まえても、開発環境というのはすべての開発現場でいつでも潤沢に用意できるわけではないので、どこか過去から構築済の環境を共有するなんてことはよくあることです。開発環境はあるブランチに紐づくことが多いため、結果としてそのブランチをみなで共有するような形になってしまい、やはりコンフリクトやテストの面で混乱を招く一因になることがあると思います。
品質（障害発生数）
元も子もない話でもありますが、障害がよく発生するとその分hotfixを入れる数が増えてしまうので、developブランチよりもmainブランチのほうが少し進んでいる、なんてことが常態化することもあるのではないでしょうか。定期的なリリースなら定常作業としてmainをdevelopにマージしておくことを忘れることはないでしょうが、hotfixのように緊急で慌ててやっているようなケースではmainからdevelopへのマージを忘れることも少なくないと思います。
開発中に発見したバグについても同様で、そういうものほどJIRAやGithubのissueで管理していなかったりするので、どこかの修正に混ぜ込んでしまうことでコードレビュー時にあまりよく見られなかったりしてあまりチーム全体で認識されないままいつの間にかリリースされたのかどうかすらわからないようなことになる恐れもあります。
これらは一例ではありますが、このように品質に問題があると、それだけでブランチの状況を把握することを難しくしてしまう要因になると思います。
リスクを考えつくしてから計画に落とす
ここまで読んでくださった中には一部の話について”少し考えすぎでは？”と思う方もいたのではないかと思います。ですが、私は品質問題は場合によってはサービスに致命傷を与える非常に重要な問題だと思っていますので、リスクを考えつくすという意味ではまずはレアでも最悪のケースや考えすぎくらいのことを一度は考えておくことが必要だと思っています。
あとはそこから考えだして、”それは考えすぎだし考慮しなくていいよね”とか”そこまでケアする工数がないから後回しで”、とあとから計画に盛り込むかどうかを判断すればいいと思います。
では、このように洗い出したリスクを考慮することによって、どのようにブランチ戦略を考えていけばよいでしょうか。ご存じの方も多いと思いますが、既に様々なブランチ戦略が紹介されています。よく聞くものでは、以下が多いと思ってます。
- git-flow
- github-flow
- gitlab-flow
それぞれがめちゃくちゃ名前が似ていますが、その戦略は少しずつ違います。以下の解説記事が図もあってわかりやすいので詳細が知りたい方はこちらを参照してください。
どの戦略もメリットやデメリットがありますが、問題はどの戦略が自分のチームに最も使えそうか、を考えることです。しかも、これらの戦略はそのまま使うことがよいのではなく、自分のチームに合わせて使えるところは使う、というのが必要なことかと思います。
以前以下のような記事を書きましたが、このブランチ戦略についても同じことが言えます。
結局、ここで紹介した戦略はいわゆるフレームワークの一つであり、それを利用することが目的化してはならず、それらを利用して品質問題やリリース運用の安定性を改善することを目的としなければなりません。
そういったカスタマイズを考えようとしたときにその検討材料となるのが最初に紹介した5つの事情ではないかと私は考えています。
チームの事情から最も使えそうなフレームワークを選定し、オリジナルのままではチームの事情に合わない部分をカスタマイズする。カスタマイズしたときにはその理由やカスタマイズした時に起きる副作用まで明確にできればなおよいです。
どんな戦略も完璧なものはなく何かすると副作用とも呼ぶべき”万が一起こるかも”な問題が出るものです。それらまでケアできるかどうかはそれこそチームの事情によるでしょう。
さらに、5つの事情はチームの状況によって変化するものであり、ブランチ戦略もその状況に合わせて変化させなければなりません。そのため定期的でもいいですし、ビジネス環境が変わったタイミングでもいいので、ブランチ戦略も見直してチームにとって品質も運用負荷も最適にしていけるといいですね。
最後に
今回はソフトウェア品質やリリース運用の安定性を確保するためにどのようにブランチ戦略を考えていけばいいかを紹介しました。
具体的な話をするとキリがないので、少し抽象的な話に終始してしまいましたが、ブランチ戦略を考える上での切り口の参考にしてもらえたらよいかなと思います。
今回のこの記事の内容そのものについても、私の経験から話したフレームワークの一つですので、このまま使えばすべての現場でうまく考えられるかというとそんなことはないと思います。
ですが、何から考えていいかわからない、というような方は一度私の考え方で戦略を作りきってみてください。一度考えきることができれば、そこから現場との差分はいくらでも考えられます。それこそ運用しながら不都合が出れば順次修正すればいいと思います。
ブランチ戦略を考えたことがない方も、考えることに困っている方も、是非一度この記事を読んでブランチ戦略をしっかりと決めてみてください。
