これはHubble Advent Calendar 2023の12日目1の記事です。
はじめに
株式会社Hubbleのフロントエンドを担当している @KOHETs です。
Hubbleでは、 Gitflow を利用して開発を行っていましたが、2020年頃からトランクベース開発に切り替えました2。今回はトランクベース開発に切り替えたことで、開発チームの考え方や文化が変わった点について紹介したいと思います。
トランクベース開発ってなに？
トランクベース開発とは、すごくざっくりいうと、プルリクエストの単位をなるべく小さくして、トランク（mainブランチ）に素早く取り込むことで高速で開発サイクルを回す手法です。
詳しく説明するとそれだけで長くなってしまうので、詳しく知りたい方、メリットやデメリットを知りたい方はこちらで詳しく解説されているのでぜひ読んでみてください。
何を解決したかったか
それなりに前の話なのでぼやっとしているんですが、確か当時困っていたことが2つありました。
- 変更点が多すぎることによるレビュー負担
- コンフリクトの解消が果てしない
これらの問題は Gitflow が機能開発が完了するまで一つのブランチで作業することを許容していることで、ブランチの生存期間が長くなることに起因していました。
そこで、思い切ってトランクベース開発に切り替えて、半強制的にブランチの生存期間を短くすることで、これらの問題を解決しようと考えました。
トランクベース開発の壁
Hubbleがトランクベース開発の導入で障壁になったのは、「機能フラグの導入」と「リリースフローとの兼ね合い」でした。
ブランチ戦略を切り替えたのはフロントエンドのみで、リリースフローも変更する予定はなかったので、このあたりをうまく調整する必要がありました。
機能フラグの導入
トランクベース開発では、リリース前の機能も積極的にトランクに取り込むため、本番環境で開発中の機能が流出しないように制御する必要がありました。
実際に機能フラグを導入するか考えましたが、機能毎にフラグを制御する必要コストはそれなりにあるので、結局導入は見送りました。
代わりに、環境変数にフラグを持ち、ローカル環境と開発環境のみフラグがONになり、検証環境と本番環境ではOFFになっているHubble内では「InProgressフラグ」と呼ばれるシンプルなフラグを導入しました。
リリースフローとの兼ね合い
トランクベース開発は、テストを自動化することで品質を保証し、トランクに取り込んだものをすぐに本番環境へ反映するようなフローを取ることが出来ます。
一方Hubbleは、元々Gitflowを利用していたのも有り、 開発環境、検証環境、本番環境それぞれに対応するブランチを用意して、それぞれのタイミングで反映するようにしていました。
これらをうまく合わせるのは難しいと思ったので、リリースは従来どおり、適切なタイミングでリリースブランチを作成して行うことにしました。
チームに起きた変化
トランクベース開発に切り替えてもう3年以上経ちますが、当時困っていたことは今は殆ど起こらなくなったので、切り替えて良かったと思っています。
プルリクエストの単位は小さく
問題だったレビュー負荷が高いプルリクエストは最近は殆どありません。作業開始からトランクへの取り込みまでは長くても数日で終わり、レビューは殆どがその日の中に終わります。
レビューの負担が小さくなったことで、レビューの質も上がり、開発サイクルも大幅の短縮に成功していると思います。
気軽に使える機能フラグ
機能フラグは高度な制御をする上では必須です。しかしHubbleでは環境毎の出し分けさえできればよかったので今でもInProgressフラグのみで運用しています。
機能フラグと比べて圧倒的に気軽に利用できるため、開発者の心理的な負担も少なく、機能フラグの導入を見送ったことは正解だったと思っています。
まとめ
トランクベース開発の導入によって、辛かった作業から開放され、開発サイクルも大幅に短縮できたのは大きな収穫でした。
また、トランクベース開発のメリットをすべて取り込もうとせず、適切な距離感で取り込んだことも良かったです。
もちろん今後は機能フラグの導入や本番環境への即時反映なども検討していきたいですが、それは未来の僕が頑張ってくれることに期待しています。
明日は @nohata さんです！