回答:
機能フラグは、長寿命のブランチや製品開発の競合を回避するために使用できるエンジニアリングデバイスです。オブジェクト指向言語のコンテキストでどのように使用して、開発者が新しいバージョンを処理しながら特定の製品機能で協力できるようにする方法を次に示します。このソリューションは、「インターフェイス」の概念が存在する場合、非オブジェクト指向のコンテキストでも使用できます。（OCamlモジュールシステムを参照。）
説明のために、データベースに保存されているデータに関するレポートを表示するツールを想定しています。コードは、リクエストの実行に使用されるDatabaseClientクラスを実装します。データセットが大きくなると、代替のデータレイアウトによってアプリケーションのパフォーマンスが向上することが明らかになります。そのため、アリスは改善されたレイアウトで構造からデータを取得できるDatabaseClientの新しいバージョンを開発し、ボブは歴史的なDatabaseClientを維持します。
次の手順で、アリスとボブは短命のブランチで協力しながら、競合を最小限に抑えます。
アリスは、名前を変更DatabaseClientをするDatabaseClient_v1と呼ばれる委譲クラスを作成DatabaseClientオブジェクト使用DatabaseClient_v1と実装と呼ばれるインタフェースDatabaseClientInterfaceを。（可能であれば、このDatabaseClientInterfaceはコードアーティファクトである必要がありますが、アヒル型言語は常にこれをサポートするとは限りません。）
Bobは1でAliceによって行われた変更をレビューし、彼の保守作業がDatabaseClient_v1で行われるべきであることを認識しています。
アリスは、DatabaseClientデリゲートの動作を制御する新しい構成フラグをアプリケーションに導入し、DatabaseClient_v2プレースホルダーを実装します。これは、メソッドがすべて「未実装」例外をスローするDatabaseClientInterfaceを実装するクラスです。
この後、アリスとボブは、それぞれの反復で記述されたコードがDatabaseClientInterfaceの影響を受けるため、明示的な同期なしでコラボレーションできます。これにより、同時作業による競合のリスクが最小限に抑えられます。
本番環境ではコードが使用のために選択されず、完全に機能する必要がないため、テストの実装、メソッドの実装、または部分的な実装など、Aliceからの反復は非常に短い場合があります。自動化されたテストスイートは、なるように設定する必要がありDatabaseClientInterfaceが常に使用DatabaseClient_v1がアリスを簡単に切り替えることができながら、DatabaseClient_v2またはカスタムCIのセットアップに-ローカルでテストスイートを実行するとき。すべての準備が整ったら、DatabaseClientデリゲートを管理する構成値を更新することにより、単一のコミットで変更を実行できます 。
手順は非常に「簡単」です。機能フラグアプリに移行するには、基本的に次の2つが必要です。
機能フラグの基本は、それらをオン/オフにすることですが、すぐにランプアップ方式で新しい機能をリリースすることをお勧めします。たとえば、アプリをホストする5台の1台のサーバーが起動する機能を「オン」にし、次に、すべてのサーバーが「オン」になるまで、別のサーバーで機能をオンにします。
これは、あなたの機能がそれなしでアプリと互換性があることに注意しなければならないことを意味します（例えばDBの余分な列）。
車輪の再発明を避けるために、フレームワークはさまざまな言語で存在しますが、現在メンテナンスされていないEtsyのフレームワークには、その仕組みを説明する興味深いreadmeがあります。
組み込みソフトウェアの世界では、アプリコード自体（たとえば#define/ #ifdefステートメント）やビルドツール構成ファイル（たとえば、）でビルド時フラグを使用することがよくありますmakefile。
ビルドフラグは、機能だけでなく、あらゆる種類のコードリファクタリング、移行、デバッグサポートなどにも同様に使用できます。ビルドを壊したり、すでにブランチで機能している機能/プロジェクトでリグレッションを引き起こしたりすることなく、統合ブランチの部分的または未検証の変更をコミットできます。継続的な統合方法で、大きな/危険な/遅い進行状況の変更（そうでなければ、長期間有効なブランチを必要とする）と共にポイント修正を処理するのに最適です。
ただし、既存のブランチコードのリグレッションの検証に加えて、新しいコードの進行状況/安定性の検証を実行することもできます。このためには、ビルド時フラグを切り替える必要があります。
フラグを切り替える1つの方法は、同じブランチのCIシステムの別個の検証パイプラインで（そのような機能をサポートしている場合）、フラグを切り替えるパッチファイルを使用することです。ビルドします。異なる成果物のセットがこのワークスペースに構築され、検証されます。
あるいは、長寿命の機能ブランチをメイン統合ブランチからプルすることもできますが、この機能ブランチでの唯一の変更は切り替えフラグです。この小さな変更により、機能ブランチは自動的に非常に高速に同期できます。実際には、メインの統合ブランチを非常に密接にシャドウイングします。このブランチでCIを個別に実行する場合、予備のパッチファイルはもう必要ありません。そのような機能ブランチを長期間にわたって持ち歩くことは簡単です。
メインの統合ブランチで、新しいビルドアーティファクトを作成することもできます。このビルドアーティファクトは、実際には既存のビルドアーティファクトのクローンですが、フラグを切り替えます。この方法では、メインブランチで新しいコードを検証するために、予備のパッチファイルも機能ブランチも必要ありません。