継続的デリバリの基礎としてのトランクベース開発

Dave Farley氏とJez Humble氏は、2011年に継続的デリバリに関する重要な書籍を出版する前から一貫して、トランクベースの開発の重要性を訴え続けている。Farley氏は先日、改めてトランクベースの開発について記事を書き、3月のPIPELINEカンファレンスでの講演 “Optimising Continuous Delivery”の後に受けた異論に対して反論した。これに応じてHmble氏も、Twitterの長いスレッドで自身の見解を表明し、トランクベース開発とプログラマの思考との関係を理解すべく、その文化的側面を検証している。

Farley氏はトランクベース開発について、自身が“最も反論を受けている”プラクティスだ、と説明している。トランクベース開発とは、少なくとも1日1回、増分的な変更を、常時リリース可能なメインラインの共有トランクにプッシュして開発を進める方法である。機能ブランチを長期間使用するプラクティスとは対象的なこの方法では、構築中のプロダクトに利害関係を持つ全員を対象として、情報とフィードバックの速やかな共有が促進される。“大部分のチームは、開発中の’機能’が完了するまで、自らのブランチをマージしようとはしません。” トランクベースの開発を継続的インテグレーション(CI)と継続的デリバリ(CD)の基盤と考えるFarley氏は、このように指摘した上で、このフィードバックの乖離はCIのプラクティスに反するものだ、と述べている。

... 可能な限りの頻度で変更を公開するものがCIであるならば、私たちのアイデアに対して多くのフィードバックを得ることが可能になります。ブランチは、どのような形であれ、変更を隔離するものです。ブランチは、その設計上、コードの部分的な変更を他の開発者から隠蔽することを目的としたものであって、CIとは相反しています。ヒントは“継続的インテグレーション”という名称にあります。

Farley氏は機能ブランチについて、ダイナミックに変化するコードベースにおいて、しばしば誤解を招くような安定性をもたらすものだ、と説明する。

機能ブランチは開発者個人の観点からは非常に優れたものですが、チームの観点からは最適解とは言えません。私たちはみな、他人がやっていることは無視して、自分自身の作業に没頭したいと思っています。残念ながら、コードはそうではありません。美しく責務分離され、素晴らしく疎結合に設計された、極めて優れた構造のコードベースであっても、変更はシステムの他部分に何らかの影響を与えるのです。

この点についてHumble氏は、トランクベースの開発とは“個々のニーズよりもチームのニーズに重きを置く”ものだ、と記した上で、効果的なトランクベースの開発がコミュニケーションと小バッチによる開発を促進する点を指摘している。

私たちはバージョン管理を使用してコミュニケーションし、自分たちがやっていることをチームの他メンバに伝えます。これを十分な頻度で行うためには、非常に小さなバッチで作業する必要があります。これは多くの開発者が好む - ウサギ穴に閉じこもってコーディング作業し、何日か後に再び現れるという - 方法とは対極をなすものなのです。

CIとその前提条件であるトランクベースの開発は“社会的なチーム”活動であり、“ヒーローとしての開発者という神話に異議”を唱えるものだ、とHumble氏は書いている。

要するに、機能ブランチ対CI/トランクベース開発がなぜこれほど重大な問題なのか、という問いに関する私の仮説は、“よい”プログラマとは何かという中核的な信念のひとつを、この問題が対象にしているから、というものです。人々は小さなバッチで働く練習を受けておらず、それを不快に感じる、という事実もあります。

リリース予定に一致しないブランチに対して、チームがテストやフィードバックループ獲得に投入する労力を考慮して、Farley氏は次のように言う。

決定的なポイントは、トランクへのマージ時点で発生するテストです。“私の変更部分は、他の人のものと合わせても大丈夫です”、と素直に言えるのは、この時点までです。それまでは、他の誰かが別のブランチで、自分の修正を台無しにするような恐ろしいことをしていないように願っているのです。

トランクベースの開発はCIとCDで成功を収める上で核となるコンポーネントである、とFarley氏は記している。

CIは自然発生的なアプローチではありません。世界中で最も成功を収めた企業において考え尽くされ、広く実践されるようになったものです。トランクベースの開発は、CIおよびCDのコアプラクティスです。トランクベースの開発がなければ、CIとCDのすべてのメリットを達成することは極めて困難になります。

Farley氏はこれまで、“State of DevOps Report”や、さまざまなチームのサイズ、プログラム言語、規模で数十年間にわたってこのプラクティスを成功させてきた自身の個人的経験を引用して、トランクベース開発に対する異論を否定し続けてきた。

Humble氏は先頃、継続的デリバリを実践する企業のインパクトを経験論化し、比較検討し、統計的に数値化するという課題に取り組んだ、“Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations”という書籍を共著で発表した。Farley氏のポストに関するTwitterスレッドの中で、氏は次のようにツィートしている。

... 私たちは“State of DevOps Report”の中のトランクのみによる開発事例について、いくつかの調査を行ないました。この内容は、新刊の“Accelerate”でも紹介しています。結果は明らかです。トランクのみ、あるいは1日以内のブランチで作業したチームは、大幅に高いパフォーマンスを示しています。

“Accelerate”の前書きでは、Martin Fowler氏が、これらのプラクティスで開発することのメリットについてまとめている。

本書の中で氏らは、一般的な組織であれば数ヶ月を要するようなコードのメインラインへのコミットから本番稼働までの作業を、効率的なITデリバリ組織が1時間程度で実施している方法について説明しています。これによって彼らは、数ヶ月に1回ではなく、1日に数回ソフトウェアを更新し、市場拡大やイベントへの対応のためにソフトウェアを活用する能力を向上し、競合他社を上回る速さで機能をリリースしています。このような応答性の大幅な向上は、安定性を犠牲にしたものではありません。これら組織の頻繁なアップデートは、パフォーマンス面で劣る他社と同じ程度の割合で障害を発生させますが、通常は1時間以内に修正されるからです。