Comparators―比べてみればわかること

第3回 ブランチvs.フラグ

この記事を読むのに必要な時間:およそ 3 分

とっておきの変更

ソフトウェアをいつでもリリースできるようにしろと求める継続的デリバリの広まりにより,毎日のようにソフトウェアがリリースされるようになりました。早いうちからコードを野にさらせば,隠れた問題を前もって見つけることができるからです。

短いリリース間隔に身を置くと気づくことがあります。⁠リリースできること」「リリースしたいこと」は,必ずしも一致しないのです。たとえば大規模なビジュアルデザインの変更やとっておきの新機能を想像してみましょう。こうした粒度の大きい変更は,たとえ動作する,つまりリリース可能な状態でも,そのまま衆目にさらしたいとは限りません。期待を裏切らない形でお披露目したい,とっておきの変更があります。息を飲む新しい体験がもたらすユーザの驚きや喜びも,ソフトウェアにとっては大切な財産だからです。

とっておきの変更を仕上げるには時間がかかります。一方で,その仕上げが終わるまでソフトウェア全体のリリースを先送りするわけにはいきません。すでにリリースされた部分を少しずつ直していく日々の変更は,できるだけ早くユーザに届けたいからです。⁠とっておきのバグ修正」なんてありません。

日々の変更をこまめにリリースしつつ,舞台裏でとっておきの変更を仕立て上げたい図1)⁠継続的デリバリを行う開発チームにはそんな要望があります。ブランチとフラグは,この欲張りをかなえる代表的なテクニックです。

図1 日々の変更ととっておきの変更

図1 日々の変更ととっておきの変更

ブランチとフラグ

とっておきの変更を開発する古典的な方法がブランチです。バージョン管理システムの上に新機能開発用のブランチを作り,変更はブランチに加えます。そしてブランチが仕上がると,それをトランクにマージするのです。フィーチャーブランチとも呼ばれるパターンです。

ブランチを作らず,トランクだけでとっておきの変更を開発する流儀もあります。それがフラグです。コマンドラインフラグなど,外部から設定可能なグローバル変数をフラグと呼びます。あるフラグの値が有効なときだけ動作するよう新機能を実装すれば,未完成なとっておきの機能をフラグで無効化したままリリースできます。フラグの裏にコードを隠すのです。フィーチャートグルと呼ぶこともあります。

ブランチの利点とフラグの欠点

ブランチの利点は,その隔離度の高さです。ブランチで開発をしている限り,トランクにある既存の機能に影響を与えてしまう心配はありません。トランクだとそうはいきません。うっかりフラグを有効にしたままコードをリリースするだけで,せっかくのとっておきが台なしです。うっかりせずとも,コードがリバースエンジニアリングされてしまうことだってあります。

もう一つ,ブランチには潔さ(いさぎよさ)という利点があります。ブランチを使うと,新しい機能で置き換えられる古い機能のコードを消すことができます。おかげでコードをシンプルに保てます。フラグを使った開発では,古い機能を残しつつ新しい機能を追加します。そのためコードは複雑になりがちです。消され損ねた古いコードが少しずつ積み重なり,ソフトウェアの首を締めます。チームによってはFixitsなどと呼ばれる大掃除で不要コードのクリーンアップに取り組むこともあります。

ブランチの欠点とフラグの利点

ブランチの欠点は,マージ作業の難しさです。まず日ごろから,トランクの変更をブランチに取り込む必要があります。そうしてトランクからの乖離(かいり)を減らすのです。

マージには衝突がつきものですが,衝突の解決は必ずしも簡単ではありません。2つ以上のブランチがあると,事態はさらにややこしくなります。2つの新機能ブランチAとブランチBを持つソースツリーを考えましょう。AもBもトランクの変更は取り込みますが,互いの変更は取り込みません。AとBは大きく離れていきます。

あるときブランチAがトランクにマージされたとしましょう。ブランチBの開発者には地獄が待っています。巨大な変更が,突然トランクにやってくるからです。乖離を避けようと日ごろこまめにトランクをとりこんできた,そんな苦労は台なし。ここでもし3つ目のブランチCがマージされたら……,ぞっとしますよね。フィーチャーブランチは並列性が低いのです。

フラグにこうした問題はありません。フラグが増えるほどコードは複雑になりますが,その複雑さはコードの中に溶け込んでいるため,マージのように複雑さが一度に打ち寄せる危険が少ないのです。

実験志向とフラグ

ブランチもフラグもそれぞれファンがいるものの,継続的デリバリの世界に限ればフラグが人気を高めつつあるようです。特にリーンスタートアップ注1に類する実験志向のソフトウェア開発で,フラグは避けて通れません。

実験志向の開発では,大半の開発中コードをフラグで隠します。開発中の機能を一部ユーザだけに公開して反応を見る「実験」のためです。実験するコードはとっておきの変更に限りません。フラグを使えばA/Bテストも簡単です。開発者はさまざまなフラグの組み合わせで評価を集め,機能の取捨選択や改善を行います。従来のベータ版よりもっと早い段階から,頻繁に,小さな単位で,さまざまな相手に,機能をリリースして評価を集めます。フラグはこうした実験の舞台を支えています。

Webベースのソフトウェア開発に使われるフラグの実装にはまだ決定版がなく,ソフトウェアやサービスごとに開発されているのが現状のようです。以降ではいくつかの実装を眺めながら,それぞれの個性を紹介します。

注1)
WEB+DB PRESS Vol.68の特別企画「⁠速習]リーンスタートアップ」を参照してください。

Flickr Feature Flippers

Flickrの開発チームはアンチブランチ主義で知られています。書籍『スケーラブルWebサイト』注2ではその一端を見ることができます。そんなFlickrはブランチの代わりに,Feature Flippersと銘打った内製のフラグ実装を使っています。Flickrのコードベースに埋め込まれ,フラグの操作画面までを備えるスクリーンショットからは,Feature Flippersが開発プロセスの一部である様子が窺(うかが)えます図2)⁠

Feature Flippersのアイデアは多くのWeb開発者を刺激したようです。Webを検索するとさまざまなフレームワーク用の実装を見つけることができました。

図2 Feature Flippersの管理画面

図2 Feature Flippersの管理画面

※出典:http://www.flickr.com/photos/rossharmes/4153769740/

注1)
Cal Henderson著/武舎広幸他訳『スケーラブルWeb サイト』オライリー・ジャパン,2006年

著者プロフィール

森田創(もりたはじめ)

平日はWebブラウザの開発,休日はWebブラウザの利用に従事。最近の趣味は/etc/hostsファイルに中毒性の高いWebサイトをリストし,127.0.0.1にリダイレクトすること。現在7サイト。スマートフォンの勉強をしなければと思いつつ/etc/hostsにアクセスできない端末を持つのが不安で躊躇している。

http://steps.dodgson.org/

コメント

コメントの記入