トランクベースの開発に対する認識不足と安易なフィーチャブランチによって，多くのチームが継続的インテグレーションを知らずに放棄している，とSteve Smith氏は言う。氏はAgile Tour London 2015で，継続的インテグレーションの終焉をテーマとした講演を行う予定だ。
InfoQはSteve Smith氏にインタビューして，さまざまなブランチアプローチ，それらを継続的インテグレーションと組み合わせる方法，ビルドフィーチャブランチが継続的インテグレーションと継続的デリバリの障害となる理由などについて聞くことにした。
InfoQ: 現在利用されているさまざまなブランチアプローチについて，簡単な説明をお願いします。
Steve Smith: 分かりました。私はここ数年，さまざまなバージョンコントロール技法をテーマとして，一連の記事を執筆してきました。いずれも私自身のキャリアに基づくものです。それらの歴史的背景を評価した上で，機能ブランチのさまざまなスタイルの分類法を確立し，継続的インテグレーションとの適合性を評価したいと思っていました。そうすることで，“ビルドフィーチャブランチ(Build Feature Blanching)がうまくいっているのに，なぜトランクベース開発を検討する必要があるのか？”，という同僚からの質問に答を出したかったのです。
保守的で息の長い技術であるリリースフューチャブランチ(Releae Feature Branching)は1990年代，ClearCaseやPerforce，MKSといったツールとともに一般的になりました。開発者は分岐された機能ブランチ上で数週間ないし数ヶ月，場合によっては数年間にわたって，すべてのエピックの開発とテストを行った上で，その内容を製品版にリリースします。その後にはトランクへの辛く長いマージ作業，回帰テストが待っているのです。私はこのような作業を，MKSを使って２年間続けてきました。人に勧められるものではありません。
2000年始め頃からトランクベース開発(Trank Base Development)が，SubversionやPerforceなどのツールを使って行われるようになりました。開発者はトランク上で作業して，小さなステップで段階的に，１日に何度もコミットします。テストはトランク上で，製品リリースはトランクまたは一時的に設けたリリースブランチ上で実行します。機能開発が並行する場合は，ユーザの好みや実行時の構成を考慮しながら，フィーチャートグル(Feature Toggles)やBBA(Branch By Abstraction)その他のテクニックを用いて実施します。私はトランクベースの開発を7年間，3つの会社で，Subverson, Mercurial, Gitを使って行ってきて，すべての人に – 同僚や家族，友人，通りで会った知らない人にも – 強く勧めてきました。
2000年代半ばになって，DVCS(Distributed Version Control System)が主流になりました。その中で，トランクベースの開発がVCSにもDVCSにも適用されるようになる一方，DVCSのブランチ生成の容易さから，それまでよりも軽量なフィーチャーブランチの手法が現れたのです。そのひとつであるインテグレーションフィーチャーブランチ(Integration Feature Branching)は，GitやMercurialなどのツールで使われるようになったものです。開発者は個々のフィーチャーブランチ上で作業した後，理想的には１日単位で，その成果をテストするため，長期間運用されているインテグレーションブランチにマージします。その後インテグレーションブランチは，一定のタイミングでトランクにマージされるか，あるいはGitFlowであれば，トランクの前にフィーチャーリリースブランチにマージされます。インテグレーションフィーチャーブランチはGitFlowを使って６ヶ月程やってみましたが，まったくお勧めできません。
その後，2000年代後半には，GitやMercurial, 特にGitHub Flowの影響もあって，ビルドフィーチャーブランチ(Build Feature Branching)が突如として現れています。開発者は個々のフィーチャーブランチ上で作業した後，理想的には１日単位で，作成した機能をテストと製品リリースのためにトランクにマージします。ビルドフィーチャーブランチは客先で，GitHub Flowを使って１年ほど行いました。お勧めできますが，ただし慎重さが必要です。
InfoQ: さまざまなブランチのアプローチがありますが，それらを継続的インテグレーションとどのように組み合わせられるのか，詳しく説明して頂けますか？
Steve Smith: まず最初に，継続的インテグレーションはツールではありません。チームの全メンバが最低でも１日１回コミットして，必要ならばJenkinsやTeamCityなどビルドサーバで検証を行うという，プラクティスのひとつなのです。ですから，トランク(マスタと呼んでもよいでしょう，どちらでも構いません)へのコミットがどの程度容易になるかという視点で，バージョン管理の方法を評価することも可能です。いずれにせよ，リリースフィーチャーブランチとインテグレーションフィーチャーブランチが，どちらも継続的インテグレーションに適していないことは明らかです。前者は共有ブランチ上で何ヶ月も作業することになりますし，後者はトランク以前のブランチが煩雑です。
トランクベースの開発は継続的インテグレーションと同義で，全チームメンバがトランクに１日何度もコミットすることによって継続的インテグレーションが実現されるという，正当な理由があります。検討すべきメリットは他にもあります。チームメンバに対してコードベースをより小さく分割するように仕向けることや，モジュール化された進化型アーキテクチャ(Evolutionary Architecture)や機能トグル(Feature Toggle)を使ったカナリアリリース(Canary Release)やダークローンチ(Dark Launching)などが例としてあげられます。
ビルドフューチャブランチには興味が尽きません。個々の機能ブランチをレビューしてトランクにマージする部分からは，継続的インテグレーション向きであるようにも思えますが，よくよく考えた結果，私としては，そうではないという結論に達しました。開発者が変更範囲を欲張るので，フィーチャブランチは１日では終わりません。開発者は忙しいので，レビューも１日では終わりません。その結果，トランクへのマージとビルドの同期を取ることができず，結果としてビルドが遅れたり，失敗したりすることになるからです。
InfoQ: Agile Tour Londonでは“継続的インテグレーションの終焉”について講演するということですが，なぜ終焉(Death)なのでしょう？
Steve Smith: 2014年の#IsTDDDeadの議論の間，自分のチームの状況を確認してみたのですが，その時に，全員がテスト駆動開発とGitHub Flowを実践していることに気付きました。そのため，“テスト駆動開発には何も問題はなくて，継続的インテグレーションの方に本当の問題があるのではないか”，と疑うようになったのです。
ビルドフィーチャブランチは今，驚くほど人気ですが，その理由は a) GitとGitHubが素晴らしいツールであること，b) 企業のアイデアやインスピレーションがますますオープンソースコミュニティに向かっていること，の２つにあると思います。Stack Overflowの2015年の調査によると，16,694人中11,519人(69%)の開発者がソース管理ツールとしてGitをあげていますし，2015年6月のGitHub Pressでは1,000万のユーザと2,600万のリポジトリが報告されています。実際，Gitはすばらしいツールです。GitHubもそうです。ですが，継続的インテグレーションは –l 継続的デリバリの基本として – とにかく重要なのです。ビルドフィーチャブランチを盲目的に採用すれば，多くのチームが長期的で持続的な継続的デリバリの実現に苦労するのは目に見えています。
InfoQ: InfoQの読者がブランチや継続的インテグレーションについて，より詳しく学ぶためのリソースを紹介して頂けますか？
Steve Smith: 継続的インテグレーションの詳細については，Martin Fowler氏による継続的インテグレーションの起源となった記事や，James Shore氏とShane Warden氏による“The Art Of Agile Development”の２つをお勧めします。ブランチモデルとソース管理に関する情報としては，Paul Hammant氏のブログが情報の宝庫と言えます。
InfoQではAgile Tour London 2015について，ニュースやQ&Aなどの記事で報告する予定だ。
第３回のAgile Tour Londonが，2015年10月23日(金)に開催されます。アジリティに興味をお持ちならば，アジャイル実践家から初心者まで，どなたでも参加可能なイベントです。