トランク ベース開発

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

Kev Zettler Kev Zettler

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小さなバッチで開発する

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

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

機能フラグ

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

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

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

CI/CD の達成を目的とした最新のソフトウェア プロジェクトには、自動テストが必要です。リリース パイプラインのさまざまな段階で実行される自動テストには、複数のタイプがあります。短い実行ユニット テストと統合テストは、開発中およびコード マージ時に実行されます。実行時間が長くフル スタックでエンド ツー エンドのテストは、後のパイプライン フェーズで完全なステージング環境または実稼働環境に対して実行されます。

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

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

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

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

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

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

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

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

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

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

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

結論

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