トランクベース開発は、継続的インテグレーションと継続的デリバリー/デプロイ（CI/CD）を実践しているチームが頻繁に使用するブランチ戦略の 1 つです。
トランクベース開発では、機能またはバグ修正を別のブランチで開発して後のステージでマスターにマージするのではなく、直接変更をマスターブランチ（「トランク」と呼ばれます）にコミットします。
変更をマスターブランチにコミットすると、CI/CD パイプラインがトリガーされます。 パイプラインで何らかの失敗が検出されると、すべての担当者ができるだけ早期に修正する責任があります。 変更が頻繁にリリースされるようにマスターブランチをデプロイ可能な状態に維持しておくことがその狙いです。
CI/CD の原則に精通しているのであれば、前述の説明から、トランクベース開発が継続的インテグレーションとデプロイに最適であることに気づいたことでしょう。 チームの全メンバーが定期的に変更をコミットする限り、全員の変更の可視性と、構築されているものに対して定期的かつ迅速に得られるフィードバックのメリットを得ることができます。
マスターブランチの健全性とリリース可能な状態を維持できる優位性があるため、誰もが変更を行いながらそのテストを追加することができます。 テストカバレッジのメトリクスを監視すると、これを監視するのに役立ちますが、全員がコミット前にローカルで構築（そして一連の基本的な自動テストを実行）できるようにすることで、マスターで検出される課題の数を低減することができます。
トランクベース開発の一部の支持者は、これが継続的インテグレーションを達成する唯一の方法であり、開発ブランチまたはフィーチャブランチを使用すると、CI/CD のメリットを弱めてしまうと述べていますが、 トランクベース開発にもその欠点があります。
パイプラインの全ステージを合格するコード変更が自動的にリリースされるという点で、継続的デプロイに最適ではありますが、このモデルは、継続的な更新が期待されており、それに対する高い耐性を持つ SaaS 製品で最も良く機能します。
インストール型の製品またはモバイルアプリを構築している場合は、パイプラインを通過してくる更新ごとに新しいバージョンを作成するのではなく、定期的にリリースできるように変更をバッチにまとめることが勧められます。
この場合はブランチを使用した方が、各リリースに含められるものを管理しやすくなり、複数の製品バージョンを継続的にサポートできるようになります。
トランクベース開発には潜在的に、大型または複雑な機能の開発を処理する場合のチャレンジがあります。 マスターに定期的に変更をコミットしながら直接本番にデプロイするには、まだユーザーには提供したくない機能を管理する方法が必要となります。
トランクベース開発の場合、フィーチャーフラグを使って機能の可視性を制御することが 1 つの方法として挙げられますが、これらを管理するのは複雑です。 もう 1 つの方法として、フィーチャーブランチを含めたブランチ戦略を採用できます。この場合、機能はリリース準備が整うまで別に維持しておくことが可能です。
CI/CD に新しいチームであれば、変更をデプロイ可能な状態に維持しながらマスターに直接コミットするのは困難な場合があります。さらには、堅牢なテストスイートを開発する時間も必要です。 それでもトランクベース開発が適しているのであれば、CI/CD 手法が成熟する過程で、その開発手法を採り入れていくことを目標とする価値はあります。
トランクベース開発は、堅牢な自動テストスイートが揃っており、複数のバージョンのソフトウェアをサポートしたり、更新をリリースにグループしたりする必要がない場合に機能する継続的インテグレーションとデプロイに最適です。 ただし当然ながら、これは唯一の手法ではなく、状況によっては、他のブランチ戦略がより適している場合もあります。