問題タブ [featuretoggle]

機能トグルについてはよく読んだことがありますが、それらを実際に使用した経験はありません。機能トグルを効果的に管理するために、人々はどのようなツールやテクニックを推奨していますか?

最も簡単な方法は、トグルを true/false 値として web.config ファイルに appSettings として保存することだと思いますが、これは特に良い方法とは言えません。

理想的には、機能トグルを管理する方法は次のとおりです。

• 削除時のトグルの使用を報告します。例: コンパイル エラー
• 古いトグルを強調表示します。つまり、機能がリリースされた後も有効なトグル

最近、「機能トグル」または「ゲートキーパー」を使用して、開発が完了するまで機能をユーザーから隠しておくというアイデアについて話している記事をいくつか読みました。Facebook と Flickr はどちらも、これを使用して新しい機能をユーザーのサブセットでテストしてから、全員に公開する方法についても語っています。

少しグーグルで検索しても、この種のことを処理するために Web アプリに追加できる既存の PHP パッケージ/ツールは見つかりませんでした。自前のものを転がすのは簡単に思えますが、必要がなければその車輪を再発明する理由はありません。これを行うための既存の PHP ツールはありますか?

記事

• Martin Fowler による機能切り替え
• Flickr DevBlog でフリップ アウト

明確化: 存在するかどうかを確認しようとしているこの部分は、どのユーザーが新機能を表示できるかを制御する管理パネルです。Flickr の例では、ホストに基づいてオンにすることができます。Facebook の例では、機能をユーザーの 5%、TechCrunch ユーザーのみ、または東海岸ユーザーのみに制限するなどの機能を追加します。

200 のオンになっている機能、まだ完成していない 10 の機能、および一部のユーザー向けにデモを行っている 3 つの機能がある場合、管理パネルは非常に重要に思えます。

フィーチャートグルのパラダイムを使いたい。具体的には、Springコンテキストに、トグルに基づいたさまざまなBean定義を含める必要があります。

私はこれに出くわしました：http：//robertmaldon.blogspot.com/2007/04/conditionally-defining-spring-beans.html、これは問題ないように見えますが、多分少し面倒です

機能の切り替えは、新しい機能に対して完全に機能します。ほとんどの場合、機能は、機能の構成に基づいて表示または非表示になる UI コンテナーで単純に囲まれている必要があります。しかし、新しい機能が既存のコード ベースに大規模な変更を必要とする場合、機能の切り替えはどのように使用できるでしょうか? 'copy & change' は使用できません。なぜなら、フィーチャー ブランチよりも明らかに悪いからです。マージの競合は発生しません。では、そのような要件に対するベスト プラクティスは何ですか?

「ゴースト」パッケージとサブを作成できるようにしたいと思います。次のようなエントリを含む構成（ini）ファイルがあります。

このファイルは解析され、後の開発者は次のような質問をすることができます。

（全体のアイデアは、MartinFowlerのFeatureTogglehttp : //martinfowler.com/bliki/FeatureToggle.htmlに基づいています）

MyApp :: Featureで呼び出しをキャッチするためにAUTOLOADを使用し、iniファイルを解析するためにBEGINブロックを使用すると、次のAPIを提供できます。

問題は次のとおりです。次のAPIを作成することは可能ですか。

MyApp :: Featureだけを持っていますか？

小文字、大文字は設定ファイルで変更できますが、ここでは問題になりません。そして、明確にしてください。実装は構成から切り離されており、MyApp :: Feature :: User :: Login :: RSAはなく、決してそうなることはありません。この機能の実装は、MyApp::Humansにあります。

MyApp :: Feature :: Foo :: Barを配置すると、そのようなパッケージが必要であることがわかります。しかし、開発者は、フィーチャーパッケージがフィーチャートグルを管理するという慣習を知っており、問題はありません。私は最初の例を見つけました（enabled（$ string）ビットを使用すると複雑すぎて読むことができません

2番目の方が良い：

3番目はさらに簡単です：

では、パッケージレベルでAUTOLOADをシミュレートすることは可能ですか？

あいさつ、ロブ。

お客様はいつアップグレードするかを選択できます。そのため、私のチームは文字通り、ソフトウェア製品の数十のバージョンを維持およびサポートする必要があります。ご想像のとおり、ホット フィックスとサービス パックをこれらすべてのフレーバーに伝播する必要があるため、多くの分岐とマージが発生します。私はこの状況に満足していません。明白な解決策は、単純に製品のバージョンをそれほど多く維持しないことですが、その明白な解決策は私には利用できません。そこで、チームのメンテナンス作業を軽減するためのクリエイティブなオプションを模索しています。ソフトウェア製品の n 個のバージョンを実装する方法として、機能の切り替えと IoC を組み合わせて使用​​することを検討しています。アイデアは、製品に単一のコード ベースを使用し、構成管理を介して動作と機能を管理できるというものです。これは、コードを複数のブランチに渡って伝播する必要がなくなるためです。これは合理的なアプローチですか、それともある問題を別の問題とトレードオフしているだけですか?

ご存知かもしれませんが、フィーチャートグルは、完全に準備ができていないフィーチャーを展開し、いくつかの構成を使用してそれらをオンにする方法です。機能は、特定の顧客（A / Bテストなど）に対してオンにすることも、準備ができたらすべての顧客に対して段階的にオンにすることもできます。

GWTPでうまくやる方法を誰かが知っているのだろうか。フィーチャートグルは2つの方法（2つのスコープレベル）で実行できると思いました。-遅延バインディングメカニズムの使用：特定のデプロイメントに必要なクラスの実装を置き換えます（プレゼンタースコープ）。-さまざまなアプリケーションページを使用する-独自のPlaceManagerを実装し、特定の展開の新機能を含むさまざまな場所に移動します（場所スコープ）。

より細かいスコープ（たとえば、プレゼンター内の一部の機能）は、「if-else」を介して制御する必要があると思います。

どの機能をオンにするかを決定するために、ある種の構成を使用したいと思います（おそらくMavenプロファイルによって制御されます）。カスタム構成要素をgwt.xmlモジュール構成に追加する方法はありますか？

フィーチャートグルを実装する他のアイデアはありますか？誰かがこの方法の経験がありますか？

ありがとう！

トグルJavaアノテーションを機能させるにはどうすればよいですか？

シンプルなフィーチャートグル：-if（toggle enabled）do x

Springでは、「プロファイル」を使用してBeanを切り替えることができます。

私はこれらを使用していて問題ありませんが、フィールドまたはクラスの注釈を切り替えたいのですが、どうすればよいですか？

ユースケースでは、jpaアノテーションを持つクラスがあります。特定の環境では、一部のフィールドが@transientであることを構成でマークできるようにしたいと思います。

機能トグルを使用する場合、テストはどのように行うのですか? 開発用コンピューターをできるだけ本番環境に近づけたいと考えています。私が見たビデオによると、機能のトグルは、特定の人々 (つまり、0 から 100% のユーザー、または選択されたユーザーなど) が機能を「使用」できるように実装されています。

継続的インテグレーションを正しく行うには、テスト時に本番サーバーと同じ機能トグル設定を使用する必要がありますか? または、機能が本番環境でオフになっていない場合は、ビルド パイプラインで自動テストを実行するときにオンになっていることを確認してください。テスト コードに機能トグルを追加したり、新しいファイルにテストを記述したりしますか? システム テストで発生しなければならないプロセスで、新機能が必須のステップになるのはいつですか?