【とらんくべーすかいはつ】
トランクベース開発 とは？
最終更新:
💡 小さな変更を早く合流させ、共通の主幹を動く状態に保つ
小さな変更を共通の主幹ブランチへ頻繁に統合する開発手法。短命ブランチやプルリクエストも使えます。レビューとテストを保ちながら、長い統合作業を避ける方法を解説します。
📌 このページのポイント
ひよこ 全員がmainへ直接コミットするの？
ひよこ 短命は何日まで？
ペンギン先生 DORAは少なくとも毎日統合し、ブランチは通常数時間という目安を説明している。一方、専門サイトでは数日以内という説明もある。絶対に24時間を超えてはいけない共通仕様ではないけれど、大きな機能が全部終わるまで統合しない運用は避けたいね。
ひよこ 早く統合すると壊れそう。
ひよこ 完成していない機能はどうする？
ペンギン先生 機能フラグなどで、コードを統合・配置することと、利用者へ公開することを分けられる。ただしフラグをOFFにすれば何でも安全というわけではない。使う状態のテストや、不要になったフラグの整理も必要だよ。
ペンギン先生 必要に応じて作る場合があるよ。主幹へ継続的に統合することと、特定のリリースを保守することは両立する。どの枝へ修正を反映するかの手順を決めて、長い統合待ちを増やさないようにしよう。
もっと詳しく知りたい人へ
PRを使っていれば、トランクベース開発？
PRという道具だけでは決まりません。短い間隔で小さな変更を主幹へ戻せるかが重要です。PRが何日もレビュー待ちになったり、数週間分を一括で統合したりすると、統合の負担を早く発見する利点が薄れます。
mainへ統合するたび、必ず本番へ公開する？
統合、デプロイ、利用者への公開は別の段階です。テストを通して主幹を動く状態に保ちつつ、必要なリリース手順を使えます。機能フラグは公開範囲の制御に使えますが、すべての変更に適用できる万能の安全策ではありません。
まとめ：ざっくりこれだけ覚えればOK！
「トランクベース開発」って出てきたら「小さな変更を共通の主幹へ頻繁に統合する手法」と思えばだいたいOK！
📖 おまけ：英語の意味
「Trunk-Based Development」 ＝ 主幹を中心とした開発
💬 trunkは木の幹で、ここでは共通の主幹ブランチを指します。枝を使わないという意味ではなく、主幹から長く離れず、変更を小さく統合する考え方です。