1
Maxim Vexlerが指摘しているように、このFlickrの投稿は、機能フラグに関する正規の初期の記事の1つであり、その使用と実装について、詳細なコードで
—
Noah Sussman
回答:
「機能フラグ」（または機能トグル）は、アプリケーションの機能（サブセクション）を簡単にオン/オフにする機能です。
たとえば、負荷が高すぎる場合にdbクエリを減らす必要がある場合は、機能セットをいくらか減らすための制御が便利だという例があったと思います。
ただし、これを使用する理由は他にもたくさんあります。主なものの1つは継続的デリバリーを有効にすることです。物事を運用/ライブにプッシュしますが、完了するまで機能を無効化/切り替えます。私たちはしばしば「開発Cookie」と呼ばれるものを使用して、未完成の機能を開発チームだけに示します。この方法では、部分的に完了した作業を本番環境でテストして（ああ、そうですか！より良い統合がありますか？）、「アントグル」（完了）して公開する前に、複数のリリース/デプロイメントでテストできます。
ASP.NET MVCランドでこれを行うのに役立つ簡単なパッケージを次に示します。https：//github.com/cottsak/DevCookie（完全な開示：私は作成者です）
Fowlerには、上記のリンクよりも長い記事があり、詳細が多くあります。
この投稿（Fowlerのサイトにもあります）では、さまざまなタイプのトグルストラテジーについて説明しています。DevCookieはメインライン/トランクベースの戦略をサポートし、記事では「リリーストグル」と呼ばれています。
Adilの回答は、このインフラストラクチャの一部が必要になる場合がある多くの用語と理由があることを強調しています。これらの必要なものの一部のみが必要になる場合があることに注意してください。たとえば、シンプルで俊敏な展開/配信ワークフローのみを有効にしたい場合があるので、シンプルなインフラストラクチャで十分です。次に、A / B、コホートテスト、および制御されたロールアウトなどの完全な#leanstartup実験に移行することを選択した場合、データ駆動型開発手法を個別のソリューションとして促進する分析ツール（ヒープなど）を検討する必要があります。。上記のすべてを実行するトグルインフラストラクチャは、肥大化と不必要な複雑化につながります。
ここまで進んだら、メインライン開発、機能の切り替え、およびTEST、QA、SIT、STAND、CROUCHのような他のばかげたアイデアについて、私のその他の考えを確認してみてください。
機能フラグは、新しいコードをデプロイせずに、構成を介してアプリケーションの一部の機能をオフにする手法です。
機能フラグは、CIスキームで重要な役割を果たします。この機能では、機能は常に展開されますが、必ずしも本番環境に「リリース」されるわけではありません。
詳細はこちら：
-編集：
機能フラグ、機能トグル、実験、および制御されたロールアウトは、シンプルでありながら強力なアイデアの代名詞です。機能ロールアウトから個別のコードがデプロイされます。簡単に言えば、それはあなたの顧客の中から誰でも-だれでも-その機能を見ることができる人を選択しながら、機能のコミットを本番環境にプッシュする機能です。
それらの一部はFacebookのゲートキーパーによって普及しました。LinkedInのLiXも良い例です。
このシンプルなアイデアを採用することで、次のような多くのベストプラクティスの基盤が築かれます。
継続的な展開/配信 -1日で複数のコードが本番環境にプッシュされます。
トランク/メインライン開発 -機能ブランチは、プルリクエスト用にのみ作成する必要があります。長命の機能開発用ではありません。
これ以上のリリーストレインはありません。
本番環境でのQA /パフォーマンステスト-実際のQAおよびパフォーマンステストは、本番環境トラフィックでの本番インフラストラクチャで行われます。広範なパフォーマンスラボとステージング環境の構築に時間を無駄にしないでください。
実験 -新しい機能がKPIの針をどのように動かすかを知ってください。
問題が発生した場合の修正プログラムまたはコードのロールバックの回避 -修正プログラムとコードのロールバックはどちらもストレスを伴い、時間がかかり、必要以上の問題につながります。代わりに、機能をオフにするか、機能を下げます。
他の人はオープンソースライブラリについて言及しています。GatekeeperやLiXなどの完全なソリューションの良い例は、Splitです。私はスプリットで働いています。
ここには多くのすばらしい答えがあり、すべてマーティンファウラーの投稿で一般化された重要で基本的な定義を推進しています。
これらは、「チームがコードを変更せずにシステムの動作を変更できるようにする」コードの断片です。
したがって、私たちは歴史的にそれらを疑似コードで表されると考えてきました：
if(app_settings["beta-mode"] == "true")
showAwesomeNewGui();
else
sameOldSnoozeFeset();
これは完全に正確な考え方であり、MattとAdilはどちらも、機能フラグのさまざまな戦術的なユースケースでうまく拡張しています。
しかし、私は、dotnetdevが最初の質問をして以来、6年間で現実がどのように進化し、変化したかを反映した、改訂された定義を提供したいと思います。私は機能フラグプラットフォームのRollout.ioで働いているので、この進化のための最前線の席を手にしました。
簡単に言えば、機能フラグはもはや、アプリケーションで機能のビットをオンまたはオフにする方法ではありません。これは、「請求書ラインアイテムとは何ですか」に「説明と通貨の金額です」と答えるようなものです。確かに、しかしそれは請求書自体のより広い点では動かない。
機能フラグは、最新のソフトウェアにおける包括的な戦略的ソリューションの戦術的なビットです。これらは、より多くの情報がある実行時まで、コードの重要な決定ロジックを延期する手段です。そして、おそらく最も重要なこととして、バージョン番号が2.7より大きいかどうかを確認する単一のチェックで、それらはもはや孤立して発生するだけではありません。それらを使用する組織は、通常、包括的なシステム全体の製品アプローチの一部としてそれらを含めています。
他の人が述べたように、FacebookとLinkedInはこれを開拓しましたが、2018年には、多くの組織がそれを行っています。開発戦略、運用戦略（または、必要に応じてDevOps戦略）、および製品戦略の一部として、ランタイムの決定ロジックの質問を延期しています。そのような質問の例を次に示します。
このような決定の多くを実行時まで延期するアプリケーションを作成するには、アドホックな方法で機能フラグをアプリケーションに投入することはできません。そうしないと、技術的な負債に埋もれてしまいます。最近では、いくつかの異なるコンポーネントを含む包括的な機能フラグ管理戦略が必要です。
それで、結局、機能フラグとは何ですか？
まあ、それらは、技術的ニーズと市場ニーズの両方に適応できるアプリケーションを作成するための幅広い戦略の重要な部分です。
機能フラグ（機能フリッピングまたは機能トグルとも呼ばれます）は、必要に応じて（たとえば、サイトが予期しないトラフィックで攻撃されている場合など）潜在的に高価な機能を有効または無効にするスイッチです。これにより、スケールアップするまで、または負荷スパイクがなくなるまで少し時間がかかります。
ここだSWIGのドキュメントからの例が。
私の会社では、そのための独自のソリューションがありました。.jsonすべてのアプリにダウンロード可能な構成（）ファイルを提供するサービスを作成しました。その構成では、機能のフラグを保存しました。その構成に基づいて、アプリは現在の機能を表示または非表示にできます。（たとえば、サイドバーのメニュー項目を表示または非表示にします）。
また、機能フラグを設定できる内部管理ページも作成しました。しばらくはうまくいきましたが、その後はユーザーターゲティングとA / Bテストを実行したいと思っていました。自分で開発するのは大変だと思ったので、サードパーティのソリューションを選びました。ここですでに述べたように、そのための多くのソリューションがあります。
カスタマイズされたターゲットグループとパーセンテージベースのロールアウトを一度にサポートするため、ConfigCatを選択しました。サポートされているオープンソースSDKはgithubで確認できます。
機能フラグ（または機能トグル）を使用すると、アプリケーションを再ビルド/再デプロイすることなく、リモートでアプリケーションの機能を有効にできます。これにより、コードを本番環境にデプロイできますが、準備ができるまで機能をリリースできません。特定のユーザーをターゲットにできるため、ベータユーザーがテストできる新機能を有効にできます。
私たちの会社では以前、LaunchDarklyおよびFeatureFlags.ioからの他の提案を使用しました。また、FirebaseのRemote configを使用してこの機能を試してみましたが、この目的にはあまり適していませんでした。
結局、オープンソースのBullet Trainと呼ばれる独自のバージョンを開発することになりました。機能フラグ/トグルとRemote Configの両方を組み合わせています。
機能フラグはいくつかの目的で使用されます。一般的な考え方は、リモートダッシュボードまたはバックオフィスに、どのユーザーにどの機能を表示するかについての制御を委任することです。
コードで機能にフラグが付けられたら、いくつかの方法を使用して、アプリケーションでどのユーザーに機能を表示するかを決定できます。1. オン/オフ -すべてまたはすべてのユーザーに機能を表示します。2. 段階的なリリース -一部のユーザーにのみ機能を表示し、その後すべてのユーザーに段階的に表示します。3. ターゲティング -特定のユーザーに、そのユーザーのプロパティまたは特性に基づいて機能を表示します。
機能フラグ（ブール）および機能構成（文字列、数値など）の制御に役立つツールは、通常、機能管理プラットフォーム と呼ばれます。Configz.ioと呼ばれる機能管理用の優れたサービスがあります。
コーディングの観点から見ると、機能フラグは、if記述している新しいコードをラップするステートメントと同じくらい簡単です。ときif文が（機能フラグがオンになっている）が真と評価され、新しいコードが実行されます。
ソフトウェアを配信する実際の例でifは、ソフトウェアが実行されている環境に応じて、上記のステートメントの評価が異なります。たとえば、アプリケーションがQAサーバーで実行されている場合、機能フラグはtrueを返し、新しい機能は見た。本番サーバーで実行されている場合、機能フラグはfalseを返し、機能は非表示になります。
私のキャリアにおける個人的な経験から、私は次の方法で機能フラグを使用しました。
顧客への機能のリリースからコードの展開を分離する。これが、開発プロセスでの機能フラグの最初の使用でした。これを使用して、マーケティングおよび製品チームと、開発とリリースを行っていたエンジニアリングチームとの間の依存関係を排除しました。機能フラグにより、リリースの数週間前にコードをデプロイできましたが、以前はリリースの前夜にコードをデプロイしていました！
本番環境でのテスト。コードをリリースするときに機能フラグを使用する前は、すべてまたは何もないイベントでした。すべての顧客が機能を取得したか、まったく機能しませんでした。機能フラグを使用して、一度に少数のユーザーに新しい機能をロールアウトできるようにしました。これにより、顧客ベース全体に潜在的な問題を起こすリスクを冒すことなく、新機能に関する貴重なフィードバックとデータを収集できました。
開発ライフサイクルにおける環境ごとの機能の有効化/無効化。開発でこれを広範囲に使用して、よりスムーズな展開プロセスを可能にしました。CI/ CDパイプラインがあり、機能フラグの使用が不可欠です。
キルスイッチを作成します。アプリケーションの特定の機能を機能フラグでラップしました。これにより、その時点でアプリケーションで発生している問題が発生した場合に、その機能を「強制終了」することができます。たとえば、負荷が高い場合は、問題を解決するためにWebサイトの重要でない機能をオフにすることができます。
複数の方法でコードに機能フラグを追加できます。
独自のライブラリを作成することは、最初は良い考えのように思えるかもしれませんが、通常はそのように始めることができます。ただし、特定のユーザーグループへのロールアウトや特定のユーザーグループのターゲティングなど、機能フラグのより高度な使用例を実装したい場合は、すぐに問題が発生する可能性があります。独自の機能フラグ実装の作成に関するもう1つの問題は、複数の言語を使用している場合、コードを複数回実装する必要があることです。
機能フラグを使用する最も簡単な方法は、Floodgateなどのオンライン機能フラグ管理サービスを使用することです。このようにして、プラットフォームですべての重労働に活用できるため、アプリケーションの機能の作成に集中できます。
次に、.NET SDKを使用してアプリケーションにFloodgate機能フラグを追加する方法の例を示します。
using FloodGate.SDK;
var floodgateClient = new FloodGateClient("API-KEY");
var flag = floodgateClient.GetValue("a-new-feature", false);
if (flag)
{
// Execute the code for my new feature here...
}
開発チームで作業していて、機能フラグを使用しておらず、チーム内のデプロイメントとコード管理で問題が発生している場合。機能フラグを使用することは、これらの問題を解決する優れた方法です。チームの開発速度を加速する機能フラグの素晴らしい副作用もあります。
Martin Fowlerがここで機能フラグの非常に詳細な説明を提供しているので、これを読むことをお勧めします。
私の理解では、機能フラグは、特定の機能を受け取るユーザーを決定することにより、機能をゲートするのに役立ちます。
たとえば、ベータ版のユーザーにのみ新機能を表示したいとします。ベータ版ユーザーの場合、その機能をオンにすると、他のユーザーには表示されません。
LDUser user = new LDUser("user@test.com");
boolean showFeature = ldClient.toggle("your.feature.key", user, false);
if (showFeature) {
// application code to show the feature
}
else {
// the code to run if the feature is off
}
一部のフロントエンドJS A / B テストでLaunchDarklyの機能フラグをテストしています-うまく機能しているようです。このサイトで機能の切り替えと機能フラグライブラリを確認することもできます。
機能フラグを使用すると、基本的に、コードを変更したり、新しいバージョンをリリースしたりせずに、機能をオンまたはオフにすることができます。アプリケーションを新しいバージョンに更新するユーザーを制御できないため、これは特にモバイルアプリケーション開発者にとって重要なソリューションです。
モバイルアプリケーション開発者にこのサービスを提供している会社がいくつかあります。
私の会社では、SaaSアプリで導入するすべての新機能に機能フラグを使用しています。パフォーマンスのメリットとは別に、新しい機能を段階的に展開することもできます。新しい機能を最初にパワーユーザーに導入し、それらのユーザーからフィードバックを得て、すべてのユーザーに展開する前に即興で提供します。
また、個々のユーザーへの提供をカスタマイズすることもできます。パワーユーザーはすべての機能を望んでいます。単純なユーザーは、基本的なものだけを望み、強力な複雑な機能すべてに混乱する可能性があります。また、販売チームがアップセルすることもできます。
もちろん、他の人が指摘しているように、ある機能がパフォーマンスの低下を引き起こしていることがわかった場合、その1つの機能を（すべてのクライアントまたは問題を引き起こしている1つのクライアントに対して）オフにすることができます。