トランク ベース開発

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

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

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

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

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

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

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

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

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

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

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

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

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

小さなバッチで開発する

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

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

機能フラグ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結論

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

アトラシアンの Bitbucket には、トランクベース開発を可能にする CI/CD 機能が組み込まれています。今すぐ試してみましょう。