機能フラグ

2010年10月29日

フィーチャーブランチ を支持する最も一般的な議論の1つは、単一のリリースサイクルよりも長くかかる保留中の機能のためのメカニズムを提供するというものです。2週間ごとに本番環境にリリースしているが、完了までに3か月かかる機能を構築する必要があるとします。リリースで未完成の機能を公開することなく、全員がメインラインで作業を続けるために、継続的インテグレーションをどのように使用しますか?私たちは、この問題にかなり頻繁に遭遇しており、機能フラグはそれに対処するための便利なツールです。

(現在、この用語としては「フラグ」が最も一般的ですが、「トグル」も広く使用されています[1]。この記事では、どちらも同じ意味で使用します。)

基本的な考え方は、保留中のさまざまな機能のフラグを定義する構成ファイルを用意することです。実行中のアプリケーションは、これらのトグルを使用して、新しい機能を表示するかどうかを決定します。

これらの決定のほとんどは、アプリケーションのユーザーインターフェースで行われます。したがって、jspを使用してWebアプリケーションを構築している場合は、保留中の機能のユーザーインターフェース部分を囲むために、一連のjspタグを使用できます。

    <toggle name="petSurvey">
      <p>Take our new <a href = 'petSurvey'>pet survey</a></p>
    </toggle>

トグルタグの実装は、フラグがオンに設定されている場合はコンテンツを渡し、そうでない場合はスキップします。他のUIテクノロジーでは詳細が異なりますが、保留中の要素をラップするという基本的な概念は同じです。

新しい価格設定アルゴリズムを導入するなど、ユーザーインターフェース要素がない機能もあります。ここでは、フラグのテストはアプリケーションコード内で行われ、条件付きテストのように単純なもの、または依存性注入を介して配線された戦略のように、より洗練されたものになる可能性があります。

トグルテストは、新しい機能が適切に非表示になるようにするために、最小限の**トグルポイント**にのみ表示する必要があります。ペット調査機能には多くの画面があるかもしれませんが、ホームページにそこへ移動するためのリンクが1つしかない場合、それはトグルタグで保護する必要がある唯一の要素です。フラグを使用して新しい機能コードのすべてのコードパスを保護しようとしないでください。ユーザーをそこに導くエントリポイントに焦点を当て、それらのエントリポイントを切り替えます。フラグの作成、保守、または削除にかなりの時間がかかる場合は、トグルテストが多すぎることを示しています。単純な条件文はトグルを実装する最も簡単な方法ですが、ポリモーフィック置換などの手法を使用して、フラグがテストされるポイントの数を最小限に抑える必要があります。

これまでは、部分的に構築された機能を隠すために使用するものとして機能フラグを説明してきました。これは、**リリーストグル**と呼ぶ種類の機能フラグです。ホジソンはまた、A/Bテストのための**実験トグル**、運用スタッフに制御を提供するための**運用トグル**、およびユーザーの異なるサブセットに対する機能へのアクセスを制御するための**パーミッションントグル**を識別しています。

私が聞いたことがある機能フラグのほとんどは実行時に設定されますが、リリーストグルがビルド時に設定される場合もあります。ビルド時トグルの小さな利点は、新しい機能のコードがリリースされた実行可能ファイルにコンパイルされないことです。

機能トグルの危険の1つは、誰かがUI機能をトグルタグでラップするのを忘れた場合の偶発的な露出です。これはテストするのが難しいです。個々の要素を呼び出さずに、非表示にする必要があるものが何も表示されないというテストを形成することは困難です。個々の要素は、同時に忘れられる可能性があります。

機能フラグについてよく寄せられる質問は、テストに関するものです。機能フラグを使用すると、テストの組み合わせ爆発が起こるのでしょうか?一般的に、機能のすべての組み合わせをテストする必要はありません。リリースフラグの場合、通常は2つの組み合わせを実行すれば十分です。

  • 次のリリースでオンになる予定のすべてのフラグをオンにする
  • すべてのフラグをオンにする

これは、統合バグを見つけたい場合にフィーチャーブランチで行う必要があることとほぼ同じです。

保留中の機能が本番環境に定着したら、リリースフラグを廃止することが非常に重要です。これには、構成ファイルとそれらを使用するすべてのコードの定義を削除することが含まれます。そうしないと、誰も使用方法を覚えていないトグルの山ができてしまいます。私が聞いた記憶に残る例では、十分なコマンドラインスイッチを処理するためにlinuxカーネルの特別な再コンパイルが必要でした。

リリースフラグは最後の手段であるべきです

リリースフラグは便利な手法であり、多くのチームが使用しています。ただし、機能を本番環境に導入する場合、それらは最後の選択肢であるべきです。

最初の選択肢は、機能を安全に製品に導入できるように、機能を分割することです。これを行うことの利点は、小規模で頻繁なリリースに基づく戦略と同じです。問題が発生するリスクを軽減し、ユーザーが実際に機能をどのように使用するかについての貴重なフィードバックを得ることができ、後で機能強化を改善できます。

部分的に構築された機能を本当に隠す必要がある場合は、キーストーンインターフェースを使用するのが最善の方法です。UIエントリポイントを除くすべてを構築し、そのUIを単一のリリースサイクルに追加します。こうすることで、非UIコードは他のすべてと完全に統合されますが、最後に最後のビットを追加するまで、何も表示または使用されません。

小規模リリースまたはキーストーンインターフェースを実行できない場合にのみ、リリースフラグを使用する必要があります。

Further Reading(参考文献)

機能フラグとその使用方法の詳細については、ピート・ホジソンの記事をご覧ください。

Acknowledgements(謝辞)

(含めるのを忘れた点を思い出させてくれたツイートをしてくれたCharles Bradley、Kent Beck、Christian Gruberに感謝します。)

Revisions(改訂)

2016-02-12に更新して、ピート・ホジソンの詳細な記事に合わせています。2023-07-14 URLとタイトルを「FeatureFlag」に変更し、テキスト中の多くの使用を「flag」に置き換えました。

Notes(注)

1: (2023年7月)ピートと私が最初に2010年代半ばにブログ投稿と記事を書いたとき、「フラグ」と「トグル」の両方が使用されていました。フィーチャービット、フリッパー、スイッチなどと一緒に。それ以来、「フラグ」が最も一般的な用語として定着したようですが、「トグル」もかなり頻繁に使用されています。