• 特集グループ
  • フロントエンド
  • スペック
  • stub_feature_flags: true (デフォルトと優先)
  • stub_feature_flags: false
  • 機能フラグの有効化（開発中）

フィーチャーフラグを使った開発

一般的に、グループまたはユーザーベースのゲートを持つ方が良く、パーセンテージのゲートを使用するよりもその方が良いでしょう。 これにより、例えばアクターに基づいてログやエラーをフィルタリングすることができるため、デバッグが容易になります。 さらに、これにより、gitlab-org またはgitlab-com グループに対して最初に有効にすることができ、他のユーザーは影響を受けません。

# Good
Feature.enabled?(:feature_flag, project)

# Avoid, if possible
Feature.enabled?(:feature_flag)

アクターに基づくフィーチャー・ゲートを使用するには、モデルがflipper_idに応答する必要があります。 例えば、Foo モデルで有効にするには、次のようにします：

class Foo < ActiveRecord::Base
  include FeatureGate
end

include FeatureGate またはflipper_id メソッドを公開するモデルのみが、Feature.enabled?のアクターとして使用できます。

開発中で機能フラグの後ろにマージされる予定の機能は、変更ログエントリを含むべきではないでしょう。 エントリは機能フラグを削除したマージリクエストに追加されるか、機能フラグのデフォルト値が true に設定されたマージリクエストに追加されるべきです。 機能が DB への移行を含む場合、DB の変更のための変更ログエントリを含むべきです。

機能フラグを自動的にオンにする必要がある場合は、チェック時にdefault_enabled: true：

Feature.enabled?(:feature_flag, project, default_enabled: true)

Project#feature_available?、Namespace#feature_available? (EE)、](https://gitlab.com/gitlab-org/gitlab/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/license.rb#L293-300) ](https://gitlab.com/gitlab-org/gitlab/blob/4cc1c62918aa4c31750cb21dfb1a6c3492d71080/ee/app/models/ee/namespace.rb#L71-85) の各メソッドは、提供された引数と同じ名前のデフォルトで有効な機能フラグを暗黙的にチェックします。

例えば、ある機能がライセンスゲートされている場合、License.feature_available? の呼び出しの一部としてフラグがチェックされるため、明示的な機能フラグチェックを追加する必要はありません。同様に、その機能が一般利用可能になった後、機能フラグを「クリーンアップ」する必要はありません。

新機能がライセンスやプランによって制限されていない場合、明示的なFeature.enabled? チェックを使用することをお勧めします。

上記の暗黙の機能フラグの重要な副作用は、明示的に機能を無効にするか、一部のユーザーに制限しない限り、機能フラグチェックのデフォルトはtrueになるということです。

これは、いくつかの小さなマージリクエストを使って機能を開発する場合や、その機能がアルファ版やベータ版であり、デフォルトでは利用できないと考えられる場合に関連します。

例として、ある機能のフロントエンドの半分をバックエンドなしで出荷する場合、バックエンドの半分も出荷できるようになるまでその機能を完全に無効にしたいと思うでしょう。 GitLab.com とセルフマネージドインスタンスの両方でこの機能が無効になっていることを確認するには、私たちの定義に従ってNamespace#alpha_feature_available? あるいはNamespace#beta_feature_available?メソッドを使う必要があります。 これにより、機能フラグが_明示的に_有効になっていない限りその機能は無効になります。

特集グループ

GitLab 9.4から、Flipperグループによるフィーチャーグループをサポートしました。

フィーチャーグループは、lib/feature.rb （.register_feature_groups メソッド内）で静的に定義する必要がありますが、その実装は明らかに動的（DBへのクエリなど）に行うことができます。

lib/feature.rbで定義されると、features API のfeature_group パラメータを通じて、指定されたフィーチャーグループのフィーチャーをアクティブにすることができます。

フロントエンド

push_frontend_feature_flagこのメソッドは、ApplicationControllerを継承したすべてのコントローラで使用できます。 このメソッドを使用すると、機能フラグの状態を次のように公開できます：

before_action do
  # Prefer to scope it per project or user e.g.
  push_frontend_feature_flag(:vim_bindings, project)

  # Avoid, if possible
  push_frontend_feature_flag(:vim_bindings)
end

def index
  # ...
end

def edit
  # ...
end

JavaScriptで機能フラグの状態をチェックするには、次のようにします：

if ( gon.features.vimBindings ) {
  // ...
}

JavaScriptの機能フラグの名前は常にキャメルケースになっているため、gon.features.vim_bindings のチェックは機能しません。

Vueコンポーネントの機能フラグにアクセスする方法の詳細については、Vueガイドを参照してください。

スペック

テスト環境のフリッパーエンジンはメモリモードFlipper::Adapters::Memoryで動作します。production とdevelopment モードではFlipper::Adapters::ActiveRecordを使用します。

stub_feature_flags: true (デフォルトと優先)

このモードでは、Flipper::Adapters::Memory を使用し、すべての機能フラグをオンバイデフォルトとし、初回使用時に永続化するように設定されます。これにより、Feature.enabled? のdefault_enabled:は上書きされ、Feature.disabled? は、機能フラグが永続化されない限り、常にtrue を返します。

機能フラグの下の動作が、特定のコンテキスト以外ではテストされないようにします。

テストで機能フラグをスタブする方法や例については、テスティングガイドを参照してください。

stub_feature_flags: false

これはメモリスタブのフリッパーを無効にし、production とdevelopmentで使用されるモードFlipper::Adapters::ActiveRecordを使用します。

このモードは、Flipper とActiveRecordとの相互作用をテストしたい場合にのみ使用してください。

機能フラグの有効化（開発中）

Railsコンソール(rails c)で以下のコマンドを入力し、機能フラグを有効にします。

Feature.enable(:feature_flag_name)

同様に、以下のコマンドは機能フラグを無効にします：

Feature.disable(:feature_flag_name)

指定したゲートの機能フラグを有効にすることもできます：

Feature.enable(:feature_flag_name, Project.find_by_full_path("root/my-project"))