二週間ぶりにメインへ戻そうとしたブランチが、衝突の山で半日溶ける。
ブランチ戦略の話になると分岐の図が主役になりがちですが、痛みが出るのは分けた瞬間ではなく、戻すときです。
この痛みを設計で消しにいくのが、トランクベース開発（Trunk-Based Development）という考え方です。
CI や CD の前提条件として名前が挙がることも多いので、輪郭を押さえておくと話の通りがよくなるでしょう。
トランクベース開発とは何か
公式サイトの定義はきわめて短く、「trunk と呼ばれる単一のブランチで協業し、他の長命な開発ブランチを作る圧力に抗う」ソース管理のモデルとされています。
出典: Trunk Based Development
狙いははっきりしていて、マージ衝突とビルド破壊を避けることです。
裏を返せば、長命ブランチは「衝突を未来へ先送りしているだけ」という見方になります。
先送りされた差分は時間とともに増え、戻すときのリスクだけが複利で膨らんでいきます。
継続的インテグレーションの定義そのものが「毎日メインラインへ統合する」である以上、トランクベース開発は CI を成立させるための土台なのですね。
「短命」はどれくらい短いのか
では短命フィーチャーブランチの「短命」とは、具体的にどの程度を指すのでしょうか。
公式サイトの記述は明確で、ブランチが生きてよいのは数日、二日を超えると長命ブランチ化のリスクがあると書かれています。
出典: Short-Lived Feature Branches
人数の条件も付いていて、ブランチに乗るのは一人まで、ペアプログラミングでも二人までです。
そこへ他の開発者が合流したり、ブランチ同士をマージしたりする使い方は想定されていません。
trunk へ戻すのはブランチを閉じるときだけで、単独で本番に出せない中途半端な commit を trunk へ混ぜることは明確に禁じられています。
つまりブランチはレビューとビルド検証の待合室であって、作業場そのものではないという割り切りです。
未完成の機能をどう隠すか
ここで必ず出てくるのが、「完成していない機能を毎日 trunk へ入れたら壊れるのでは」という疑問です。
答えはデプロイとリリースを切り離すことです。
コードは trunk に入っていても、フラグで経路を閉じておけば利用者には届きません。
大きな置き換えなら、抽象化の層をはさんで新旧を並走させるやり方も定石です。
リリース側も同様に、必要になった時点で trunk からリリースブランチを切り、出し終えたら捨てる運用が推奨されています。
trunk から直接出して、問題が起きたら前に進んで直す進め方も選択肢のひとつです。
いずれにしても、長生きするブランチを作らずに済ませるところが共通点なのです。
導入でつまずくところ
理屈は素直でも、現場に入れると引っかかる箇所がいくつかあります。
第一の壁はレビュー待ちです。
レビューが二日以上滞留する組織では、短命ブランチという前提が物理的に成立しません。
第二の壁は変更の切り方で、機能を横に（層ごとに）割らず、縦に薄く割る練習が要ります。
画面からデータ保存まで通る細い一本を先に通し、そこへ肉付けしていく順番に慣れるまでは、どうしても時間がかかります。
第三の壁は検証で、コミットのたびに走る自動テストが無いと trunk が壊れたまま放置されるので、そこだけは先に整えておきたいものです。
なお「うちは人数が多いから無理」という反論には、公式サイトが単一の trunk で 35,000 人規模が回っている例を挙げて答えています。
規模はトランクベース開発を諦める理由にならない、というのが公式の立場ですね。
最後に
トランクベース開発は、ブランチ図を洗練させる話ではなく、戻すコストを毎日少しずつ払うという選び方です。
私もまだ学んでいる途中ですが、まずは「自分のブランチが今日で何日目か」を数えるところからでも、十分に効き目はありそうに見えます。
二日を超えたら分割を疑う、という小さな習慣から始めてみてはいかがでしょうか。
以上です。
コメントを残す