💼

今話題のトランクベース開発について調べた

2022/07/27に公開

CI/CD

DevOps

トランクベース開発

tech

DevOpsの考え方として「トランクベース開発」というものを知りました。

自分が知らなかっただけで、考え方としては前から存在していたようですが、今回調べてみてめっちゃ良さそうだなーと思ったので、簡単にまとめたり感想を書いたりしてみました。

関係ないですが、本を読む時間がなかったりつらかったりするときは、

気になるワードで検索し、出てきた記事をひたすら読む
それをまとめ、自分なりに噛み砕く

というのが良いんじゃないか？と感じ始めてきたこの頃です。

トランクベース開発とは

ようは「細かいコミットを頻繁にメインブランチにマージする開発方法」ということ。

昔はSubversionなるバージョン管理アプリが存在し（知らない世界。。）、そこでは trunk という言葉があったみたいです。トランクとはGitでいうmainブランチのことで、そのリポジトリのメインを表す存在だったよう。

トランクベース開発では、少なくとも1日に1回はマージされる状態が望ましい。

メリット

トランクベース開発のメリットはやはり「細かいコミットと頻繁なマージ」にあり、これによりマージ時の競合リスクやリリースのスピードを早めることができます。

よく知る master, hotfix, release, develop, feature からなるGitFlowマージ戦略だと、

featureが長く存在してしまい、マージ時の競合で絶望することが多い
マージが頻繁に行われないのでビッグバンテストになりがち
CIの高速サイクルをうまく使えているとは呼べない

という問題がありますが、トランクベース開発では小さなコミットをすぐにmainにマージするので、競合も起こりにくく、問題があったときはすぐにフィードバックを得て改善することができます。

どうやって始める？

とまぁ、言われてみれば当たり前だよなぁと。
どうやって小さいコミットに分ける運用をやるんじゃい、という感じだったのでそのあたりをもう少し深く調べてみました。

1. CIは大前提

高速でフィードバックを得たいため、CIがあることは大前提です。
マージされるたびにユニットテスト、結合テスト、E2Eテストまで自動で走らせ、すぐに問題を特定するとのこと。

最近は、もはや自動テストが可能ではないようなアプリケーションは相手にされない世界だなと感じます。

2. コミットの前にテストを走らせる

it's essential that tests are run against code changes before commit.
DevOps 技術: トランクベース開発

コミットしたら自動でテストが走り、フィードバックが帰ってくるのかと思いましたが、のGoogle記事ではコミットする前にテストをしているようでした。

ただ、他の記事だとコミット後にテストを走らせていることが多いので、両方出来たら最善だと思います。

コミットやプッシュ前のテストとなると、git hook などを使ってローカルでユニットテストを走らせるのか、それとも何か他の良いツールがあるのかもしれません…？

3. ブランチは常に3つまで

GoogleのDevOps 技術: トランクベース開発にとんでもないことが書かれていました。

In trunk-based development, developers push code directly into trunk.

これは、もはやPullRequestが存在しない世界線です。
確かに、このやり方だと自然とコミットが細かくなりますが、CI/CDがよっぽど信用できる状態でないと導入は難しいと思います。

代わりに、

Have three or fewer active branches in the application's code repository.
Merge branches to trunk at least once a day.

という記述もあったので、こちらの方が導入障壁は少なそうだなと。ただしどうやって「3つ以下のブランチ」で運用制限をかけるのかは分からず、努力目標だと結局ライフサイクルの長い開発スタイルに戻ってしまうのを防ぐ必要があるなと思います。

4. ペアプロ導入

ペアプロをすることで、常にコードがレビューされている状態なので、

「後でレビューしてください。OKならマージします。」
や
「レビューが遅すぎ。もう頭の中は次の開発だし、ローカルもそうなんだけど。」

などの待ち時間発生による問題を解消でき、小さいコミットの見張りにも役に立つとのことです。

5. 機能フラグの導入

また新しい概念が出てきましたが、「機能フラグ」というものを使い、とある機能をオンにするかオフにするかを選択できるようにすることで、細かくコミットできるようにします。

引用（有名記事らしい）：

最も原始的なイメージは以下で、これを洗練させ、かつフラグを動的に管理できる仕組みを組み上げていくそう。

isFeatureAEnabled = true

if (isFeatureAEnabled) {
  newFunc();
} else {
  oldFunc();
}

上記の例は静的管理なので意味は薄い（使い勝手が悪い）ですが、これを動的に上手く管理できるなら確かにトランクベース開発も夢じゃないなと。

また上の記事を読んでみます。

まとめ

いま話題のトランクベース開発ですが、話だけ聞いていると確かにリリース速度も上がって良いことづく目に見えます。

ただ、実際に運用するにはDevOpsチームの高い技量が必要だったり、アプリケーションの単純さが必要だったり、開発チーム全体の意識改革なども考えたりする必要があり、そう簡単に始められるものでは無さそうです。

また「コミットを小さく」とは言うものの「どうやって小さい作業量に分割するか」というところが分からずじまいで、ここの原則を確立しないとマージされないブランチが増えてきてもとに戻る…という未来が見えるので、考えものだと思いました。

でも取り入りてみたいですね。