Close

トランク ベース開発

DevOps チーム間でこのバージョン管理が一般的なプラクティスである理由を確認する

Kev Zettler の顔写真
Kev Zettler

フルスタック Web 開発者


トランク ベース開発とは、開発者が細かく頻繁なアップデートをコア「トランク」または main ブランチにマージするバージョン管理手法です。これによってマージと統合の各フェーズが合理化されるため、CI/CD の実現、ソフトウェア デリバリーと組織パフォーマンスの向上に役立ちます。

ソフトウェア開発の初期には、プログラマーは現代のバージョン管理システムほど豊富な機能を利用できませんでした。その代わり、変更を追跡して必要に応じて元に戻す手段として、2 つのバージョンのソフトウェアを同時に開発していました。次第に、このプロセスは労働力とコストがかかって非効率であることが明らかになりました。

バージョン管理システムが成熟するにつれてさまざまな開発スタイルが登場して、プログラマーがバグを簡単に見つけて同僚と並行してコーディングし、リリース間隔を短縮できるようになりました。今日、ほとんどのプログラマーは Gitflow とトランク ベース開発という 2 つの開発モデルのいずれかを活用して、質の高いソフトウェアを提供しています。

最初に普及した Gitflow は、特定の個人だけがメイン コードへの変更を承認できる、非常に厳格な開発モデルでした。そのため、コードの品質が維持されてバグの数が最小限に抑えられます。トランク ベース開発は、すべての開発者がメイン コードにアクセスできる、よりオープンなモデルです。そのため、チームはすばやく反復処理を実行して CI/CD を実現できます。

トランク ベース開発とは何か

トランク ベースの開発とは、開発者が細かく頻繁なアップデートをコア「トランク」または main ブランチにマージするバージョン管理手法です。これはマージ フェーズと統合フェーズの流れを合理化するため、DevOps チームの間では一般的なプラクティスであり、DevOps ライフサイクルの一部となっています。事実、トランク ベースの開発は CI/CD で必須のプラクティスです。他の長く使用されている機能のブランチング戦略と比べて、開発者はわずかなコミットで短期間のブランチを作成できます。コード ベースの複雑さとチーム規模が拡大するにつれて、トランク ベースの開発は本番リリースのフローを維持するのに役立ちます。


Trunk-based development is a version control management practice where developers merge small, frequent updates to a core “trunk” or main branch. It’s a common practice among DevOps teams and part of the DevOps lifecycle since it streamlines merging and integration phases. In fact, trunk-based development is a required practice of CI/CD. Developers can create short-lived branches with a few small commits compared to other long-lived feature branching strategies. As codebase complexity and team size grow, trunk-based development helps keep production releases flowing.

Gitflow とトランク ベース開発の比較

Gitflow とは、存続期間の長いフィーチャー ブランチと複数のプライマリ ブランチを使用する、もう 1 つの Git ブランチ モデルです。Gitflow には、トランク ベース開発よりも存続期間の長いブランチと大規模なコミットがあります。このモデルでは、開発者はフィーチャー ブランチを作成して、フィーチャーが完成するまでメインのトランク ブランチへのマージを延期します。こうした存続期間の長いフィーチャー ブランチは、トランク ブランチからの乖離が大きくなってアップデートにより競合が発生するリスクが高いため、マージにはより多くのコラボレーションが必要です。


Gitflow is an alternative Git branching model that uses long-lived feature branches and multiple primary branches. Gitflow has more, longer-lived branches and larger commits than trunk-based development. Under this model, developers create a feature branch and delay merging it to the main trunk branch until the feature is complete. These long-lived feature branches require more collaboration to merge as they have a higher risk of deviating from the trunk branch and introducing conflicting updates. 

ソリューションを見る

Open DevOps によるソフトウェアの構築と運用

関連資料

継続的インテグレーションを開始する方法

Gitflow には、開発、ホットフィックス、機能、リリース用に個別のプライマリ ブランチ ラインもあります。これらのブランチ間でコミットをマージするには、さまざまな戦略があります。対応して管理する必要のあるブランチが増えるため、複雑さが増して追加の計画セッションやチームによるレビューが必要となることがあります。

トランクベースの開発は、修正とリリースのソースとして main ブランチに焦点を当てているため、はるかに単純化されています。トランクベース開発では、main ブランチは常に安定し、問題なくデプロイできる状態であると想定されています。

トランク ベース開発のメリット

トランク ベース開発は、継続的なインテグレーションに必須のプラクティスです。ビルドとテストの各プロセスが自動化されていても、開発者が分離された長いフィーチャー ブランチで作業していて共有ブランチにほとんど統合しない場合、継続的なインテグレーションはその真価を発揮できません。

トランク ベース開発によって、コード統合に対する抵抗が緩和されます。開発者は新しい作業を終えたら、新しいコードをメイン ブランチにマージする必要があります。しかし、正常にビルドできるかどうかを確認するまでは、変更をトランクにマージしてはなりません。このフェーズでは、新しい作業の開始後に修正が加えられた場合は競合が発生する可能性があります。特に、開発チームが大きくなってコード ベースが拡大するにつれて、これらの競合はますます複雑になります。これは、開発者がソース ブランチから派生した別のブランチを作成して、同時に他の開発者が重複するコードをマージした際に発生します。幸運なことに、トランク ベース開発モデルではこれらの競合を減らせます。


Trunk-based development is a required practice for continuous integration. If build and test processes are automated but developers work on isolated, lengthy feature branches that are infrequently integrated into a shared branch, continuous integration is not living up to its potential.

Trunk-based development eases the friction of code integration. When developers finish new work, they must merge the new code into the main branch. Yet they should not merge changes to the truck until they have verified that they can build successfully. During this phase, conflicts may arise if modifications have been made since the new work began. In particular, these conflicts are increasingly complex as development teams grow and the code base scales. This happens when developers create separate branches that deviate from the source branch and other developers are simultaneously merging overlapping code. Luckily, the trunk-based development model reduces these conflicts.

継続的なコード統合を実現

トランクベース開発モデルでは、main ブランチへの安定したコミットのフローがあるリポジトリがあります。このコミットのフローの自動テスト スイートとコード カバレッジ監視を追加することで、継続的インテグレーションが可能になります。新しいコードがトランクにマージされると、自動インテグレーションとコード カバレッジのテストが実行され、コードの品質が検証されます。

継続的なコード レビューを保証

迅速かつ小規模なコミットが可能なトランク ベースによって、コード レビューはより効率的なプロセスになります。ブランチが小規模なため、開発者はわずかな変更もすばやく確認してレビューできます。レビュアーがコードのページを読んだり膨大なコード変更部分を手動で調べたりする永続的なフィーチャー ブランチに比べると、はるかに簡単です。

本番コードの連続的なリリースを有効にする

チームは頻繁に、main ブランチへのマージを毎日行う必要があります。トランクベースの開発では、トランク ブランチを「グリーン」に保つ、つまり、コミット時にデプロイする準備を整えるよう努めています。テストの自動化、コード カバレッジ、コード レビューにより、トランクベース開発プロジェクトは、いつでも本番環境にデプロイできることを保証します。これにより、本番環境に頻繁にデプロイし、先の日常的な本番リリースの目標を設定できる俊敏性が得られます。

トランク ベース開発と CI/CD

CI/CD の普及によってブランチ モデルが洗練されて最適化され、トランク ベース開発の進化につながりました。現在、トランク ベース開発は継続的なインテグレーションの要件となっています。継続的なインテグレーションでは、開発者は各委員会がトランクに実施する自動テストと併せてトランク ベース開発を実行します。これによって、プロジェクトは常に動作することを保証します。

トランク ベース開発のベスト プラクティス

トランク ベース開発によって、チームはコードを迅速かつ一貫してリリースできます。チームの歩調を整えて最適なリリース スケジュールを作成するために役立つ演習と実践のリストを、次に示します。


Trunk-based development ensures teams release code quickly and consistently. The following is a list of exercises and practices that will help refine your team's cadence and develop an optimized release schedule.

小さなバッチで開発する

トランク ベース開発では、速いリズムでコードを本番環境に配信します。トランク ベース開発を音楽に例えると、速いスタッカートになるでしょう。リポジトリのコミットを音符に変換して、短く簡潔な音符を短時間で連続させます。コミットとブランチを小さく保つことで、マージとデプロイのスピードが速くなります。

数行のコミットをわずかに変更したり数行のコードを変更したりした場合は、不要な負担を最小限に抑えられます。膨大な変更セットを見直すのではなく限られたコード領域を見直すだけだったら、チームの対話は有意義なものになって簡単かつ迅速に意思決定を行えます。

機能フラグ

機能フラグは、開発者が新しい変更を非アクティブなコード パスにラップし、後でアクティブ化できるようにすることで、トランクベース開発を適切に補完するものです。これにより、開発者は別のリポジトリ機能ブランチを作成するのではなく、代わりに新しい機能コードを機能フラグ パス内の main ブランチに直接コミットすることができます。

フィーチャー フラグでは、小規模なバッチの更新を直接促します。開発者はフィーチャー ブランチを作成して完全な仕様の構築を待つ代わりに、トランク コミットを作成すれば、フィーチャー フラグを導入して新しいトランク コミットをプッシュし、フラグ内でフィーチャー仕様を構築できます。

包括的な自動テストの実装

CI/CD の実現を目指す最新のソフトウェア プロジェクトには、自動テストが不可欠です。リリース パイプラインのさまざまな段階で、さまざまなタイプの自動テストが実行されます。開発中およびコード マージ時には、短い実行ユニット テストと統合テストが実行されます。その後のパイプライン フェーズでは、実行時間が長くフル スタックのエンドツーエンド テストが、完全なステージングまたは本番の各環境に対して実行されます。

自動テストは開発者による新しいコミットのマージごとの小規模バッチのリズムを維持することによって、トランク ベース開発を可能にします。自動テスト スイートはあらゆる課題のコードをレビューして、自動で承認/拒否します。これによって、開発者はコミットを迅速に作成して自動テストを実行し、新たな課題が生じていないかどうかを確認できます。

非同期コード レビューを実行する

トランク ベース開発ではコード レビューをすぐに実行して、後でレビューする非同期システムには入れないでください。自動テストは、事前対策型のコード レビューのレイヤーを提供します。開発者はチーム メンバーのプル リクエストをレビューする準備ができたら、最初に自動テストに合格してコード カバレッジが増えていることを確認できます。これによって、レビュアーは新しいコードが特定の仕様を満たしていることをただちに確認してから、最適化に集中できます。

アプリケーションのコード リポジトリにアクティブなブランチを 3 つまで用意する

ベスト プラクティスでは、ブランチがマージされたらそのブランチを削除します。リポジトリにアクティブなブランチが大量にあると、好ましくない影響が生じやすくなります。アクティブなブランチを調べることでどこでどの作業が進行中かを確認できることは便利ですが、古いブランチや非アクティブなブランチが残っているとこのメリットは失われます。Git ユーザー インターフェイスを使用した場合は、多数のリモート ブランチをロードする際に扱いにくくなる可能性があります。

1 日 1 回以上、ブランチをトランクにマージする

実績のあるトランクベース開発チームは、少なくとも毎日、マージの準備が完了したオープンなブランチをすべて閉じ、そのブランチをマージする必要があります。この演習では、リズムを保ってリリース管理の期間を設定します。その後、チームは一日の終わりに main トランクにリリース コミットとしてタグ付けできます。これにより、毎日のアジャイル リリース増分が生成されるという便利な効果もあります。

コード フリーズと統合フェーズの数を削減する

アジャイル CI/CD チームでは、統合フェーズにコード フリーズや一時停止を計画する必要はありません。ただし、組織が他の理由でそれらを必要とする場合があります。CI/CD の「連続」とは、常に更新が行われていることを意味します。トランク ベース開発チームは、コード フリーズをブロックせずにリリース パイプラインが停止しないように計画する必要があります。

迅速に構築して即実行する

クイック リリースの間隔を維持するには、ビルドとテストの実行時間を最適化しておく必要があります。CI/CD ビルドツールでは、コストのかかる静的な計算を回避するためにキャッシュ レイヤーを適宜使用します。サードパーティ サービスに適切なスタブを使用できるように、テストを最適化する必要があります。

結論

現在、トランク ベース開発はパフォーマンスの高いエンジニアリング チームの標準となっています。これは、簡略化された Git ブランチ戦略を使用してソフトウェア リリース間隔を設定して維持するためです。さらに、トランク ベース開発では、エンジニアリング チームがソフトウェアをエンド ユーザーに提供する方法を柔軟に制御できます。


Trunk-based development is currently the standard for high-performing engineering teams since it sets and maintains a software release cadence by using a simplified Git branching strategy. Plus, trunk-based development gives engineering teams more flexibility and control over how they deliver software to the end user.

Kev Zettler
Kev Zettler

Kev はフル スタック Web 開発者のリーダーであり、10 年以上もアジャイル手法で製品やチームを構築する経験を持つシリアル アントレプレナーです。DevOps、仮想通貨、VR/AR などの新たなオープン ソース技術に熱心に貢献し、それについて著書を執筆し、教育を行っています。時間がある時には、インディーズ ゲーム開発ジャムに参加しています。


この記事を共有する

おすすめコンテンツ

次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。

DevOps のイラスト

DevOps コミュニティ

DevOps のイラスト

ブログを読む

マップのイラスト

無料で始める

DevOps ニュースレター購読

Thank you for signing up