🤔

Trunk Based Development がどうして腑に落ちなかったのか

に公開
Git
GitHub
CI/CD
scm
idea

はじめに

継続的インテグレーションの文脈でTrunk Based Development(TBD)なるブランチ戦略が謳われることが多くなりました。

この記事は、これらのキャッチーなスローガンで引かれて調べたものの、やりたいことと理想はわかるが、腑に落ちなかった点が多少あったので、それをまとめたものです。

この記事は構成管理ツールの使用経験や管理施策を考えたことがある人物を対象に、TBDという流派があるという紹介と、それを調べた時の戸惑いの一片でも共有できることを目的としています。

Trunk Based Development(TBD)とは

構成管理ツールのブランチ戦略という側面だけで言うと、この開発方針は単純です。
trunkと呼ばれるmainブランチに、直接コミットもしくは、短いfeatureブランチでマージする手法です。

Trunk-Based Development For Smaller Teams:
直接コミット

Scaled Trunk-Based Development:
短いブランチ

この単純な構成により、チームメンバーが1日に複数回トランクに変更をコミットでき生産性をあげるというのが目的になります。
後者については、いわゆるGitHub Flowに近いフローなので違和感を感じないかもしれません。
前者については、古くからこの業界にいた人は懐かしさと、Subversionを使用していた時に感じた震えを思い出すでしょう。

ブランチ戦略としては、目新しさはなにもなく、ただの懐古主義的戦略に見えるかもしれないのですが、重要なのは、Trunk-Basedで管理できるようにするという周辺施策であると思われます。
たとえば以下のようなものが挙げられます。

  • 短いコミットを実現するための細かい粒度の作業分離
  • 自動テストを完備する
    • コミット前にローカルで自動テストを動かしてからコミットする
    • コミット後に自動テストでエラーを検知する
    • 高速な自動テスト
  • 現状の動きを変えずに不安定なコードを混入できるようにする
  • 同期的なレビュー
    • ペアプログラミングやモブプログラミング

つまりTrunk-Based Developmentは単なるブランチ戦略ではなくて、その単純なブランチ戦略を支える開発方法全体を指すと私は理解しています。

この手法についてさらに詳細を調べたい方は以下を参照してください。

疑問と違和感

上記までの内容でなんの疑問も違和感を抱かなかった場合は以降の章は不要です。

以下はTrunk Based Developmentを調べて感じた違和感であり、それはTrunk Based Developmentに対する無知からくる可能性があるという前提をご理解して読み進めてください。

GitHub Flowとの違い

TBDの説明の多くはGitHub Flowとの違いを主張しています。
すくなくとも、Scaled Trunk-Based Developmentのブランチ戦略とGitHub Flowのブランチ戦略のフロー的な違いを感じません。
また、当初にGitHub Flowを紹介していたScott Chacon氏のブログでは毎日本番環境にプッシュし、継続的にテストとデプロイを行っているチームを前提としてGitHub Flowを紹介しているため、その目的にも違いが見えません。

しかし、Accelerateの一文を見てもあきらかにGitHub Flowとは違うということを主張します。

Even after finding that trunk-based development practices contribute to better software delivery performance, some developers who are used to the “GitHub Flow” workflow remain skeptical. This workflow relies heavily on developing with branches and only periodically merging to trunk. We have heard, for example, that branching strategies are effective if development teams don’t maintain branches for too long—and we agree that working on short-lived branches that are merged into trunk at least daily is consistent with commonly accepted continuous integration practices.
開発者の中には、トランクベース開発の実践がソフトウェアデリバリーのパフォーマンス向上に寄与することが明らかになった後でさえ、「GitHub Flow」ワークフローに慣れているため懐疑的なままでいる人たちがいます。このワークフローはブランチでの開発に大きく依存しており、トランクへのマージは定期的にしか行われません。たとえば私たちは、ブランチ戦略は開発チームがブランチを長期間維持しないのであれば効果的だ、という意見を耳にしてきました——そして私たちも、短命のブランチで作業し、それらを少なくとも毎日トランクにマージすることは、一般に受け入れられている継続的インテグレーションの実践と一致していると考えています。

この書籍で述べているGitHub Flowを使う人間はブランチは長く生存させており、頻繁なマージを行わない前提で描かれています。
おそらく、GitHub Flowでは厳しくルールを定義するものではないです。そのため、GitHub Flowと比較を行う場合、その行間の前提を各自が異なる形で補っているように感じられました。

Feature Branchのイメージ

前述のGitHubFlowとの差でもありましたが作業ブランチ、いわゆるFeature Branchについてのイメージが人によって異なると感じました。

  • ある人はFeature Branchは単独の作業者が細かい機能をつくるイメージですし、
  • ある人は複数の作業者が長時間共同して機能を作るイメージになっています。

Martin FowlerはFeature Branchの問題を以下のようにあげています。

  • 分離によって問題の早期発見が妨げられる
  • リファクタリングの妨げになる
  • これらの問題は短時間のFeature Branchでは顕在化しないが、数週間、数ヶ月かかる場合、問題に直面しやすくなる

そのため、Feature Branchが悪というような言説を聞いた場合、その前提条件をすり合わせる必要があります。
その上で、いかなる短命なFeature Branchでも認めない流派もあります。

なお、Trunk Based Developmentでは短命のFeatureブランチについて、Git/Mercurial の軽量ブランチや Pull Request によるコードレビュー、CI などによってブランチ運用コストが下がった結果、チーム規模が 16 人以上の場合は 短命の Feature ブランチを切ったほうが生産的だと述べています。

短命のブランチすら許容しない場合

短命のブランチすら許容ができないケースではGitHubやGitLabのPull Requestによるレビューなどが使えないことを意味します。この流派の場合、ペアプログラミングやモブプログラミングが前提となると考えられます。

GitLabのIssueにTBD用のコードレビューを希望するIssueがありますが、「現在、この分野に重点を置いていないため、この機能リクエストは終了しています」とCloseされています。

そもそもブランチをほとんど使わない前提であれば、Git の軽量ブランチや PR ベースのレビューといった特徴はあまり活かされません。
そのような前提を選ぶチームに対して価値判断をしたいわけではありませんが、技術的選択肢としては、2010年代初頭によくあったSubversion＋Review Boardなどの集中管理型のバージョン管理システムを採用する、という方向性も取り得ると思われます。
TBDの事例として、よくGoogleの事例が強調されますが、Googleのバージョン管理システムはPiperで、集中管理型のバージョン管理システムと認識しています。

構成管理システム上でTrunk-Based Developmentと判断していいのか？

私の理解ではTrunk-Based Developmentはそれができる状況とセットの開発スタイルと理解します。
そのことは構成管理システム上でブランチが1本しかないのであれば、そのプロジェクトがTrunk-Based Developmentという単純な判断は不可能ではないかと思っています。

以下の研究では構成管理上のブランチの状態をみてGitFlow,GitHubFlow,Trunk-Basedの違いを調べています。

この研究ではtrunk-based ブランチ戦略が広く使用されている結果が出ていますが、それがTrunk-Based Developmentが広く採用されていると解釈できないのではないかということです。
上記のデータでは単一の開発者のデータも入っているので当然レビューもなにもない状況のものが混在している結果です。
つまり、Trunk Based Developmentという開発手法とTrunk Based Developmentの結果生まれるブランチの戦略は別物であることを注意する必要があると思います。

TBDとバーンアウト

2023 State of DevOpsでTrunk-Based Development と燃え尽き症候群に相関が見られる、という分析があります。

レポートとしてはそういう傾向があるという話でなぜそれが発生したかの調査はしていません。

素人の推測としては、ブランチ戦略だけでなく、ペアプロや自動テスト、Feature Flagの導入などの施策を同時に行うという意味であれば、少なくとも最初は疲弊するのではないかと思われます。
新しいこと、とくにペアプロなどをやっていない環境でそれを導入すれば要員が疲弊する可能性は十分に考えられますし、１日に一回は必ずコミットをしなければならないというのは、設計を重視しているタイプの人間には合わない可能性があります。

まとめ

Trunk Based Development(TBD)なるブランチ戦略を調べました。
細かくコミットして常に結合できる状態にするという思想自体は古くからあり、理解できるものです。
一方で、これを周辺状況をととのえず...たとえば自動テストやレビューの施策をセットで整えずに、ブランチ戦略だけを適応すればいいというものではないと思います。
なので組織に適用するときはその、全体的な戦略とセットで考える必要があるでしょう。
Git Flowのときもありましたが、状況を無視した流行の採用は状況をより悪い方向へ進める場合があります。
今現在の自分自身の組織の状況、それを導入するときの副作用、副作用の軽減策などを慎重に考慮して判断する必要があるでしょう。
少なくとも「〜がやっている！バスに乗り遅れるな！！！」のノリで採用すべきものではないと思いました。

Discussion