あなたの機能は完成しました。プルリクエストはきれいです。QAはそれが良さそうだと言っています。でもあなたはそれを全員に一度に配信したくありません。
その気分は、通常、Reactアプリが単純なデプロイから成長した最初の兆候です。製品が実際のユーザーに公開されると、リリースは技術的なイベントだけではなくなります。リスクの決定になります。新しい検索UIが壊れたり、チェックアウトバリエーションがユーザーを混乱させたり、またはモバイルビルドがcodeを実行した場合、迅速に戻すことができません。 if (process.env.NODE_ENV) あなたはそれ以上のものが必要です。
それが Reactの機能フラグ start to matter. Not as a cute boolean in a component, but as a release control layer that lets you ship code separately from exposing it. In web apps, that means safer rollouts. In bundled apps like Capacitor or Electron, it matters even more because rollback speed is limited by store review, install lag, and slower release cycles.
目次
- モダンなReactアプリケーションで機能フラグが不可欠な理由
- Reactアプリケーションで機能フラグを設計する
- ロールアウトとロールバック戦略の実装
- テスト観測性とフラグの負債の管理
- フラグを保護し、CI/CDで自動化する
- ウェブ以外の機能フラグとモバイルアプリのCapacitor
Why Feature Flags Are Essential for Modern React Apps
金曜日の午後、新しい請求明細UIはすでにデプロイされており、サポートはリリースチェックリストを開いており、1つのエンタープライズクライアントはまだ月曜日のまでに古いフローを必要としています。ウェブアプリではすでに緊張しています。デスクトップインストーラーやモバイルストアから配信されるバンドルされたReactアプリでは、ロールバックが分数より時間かかるか、日数よりかかるため、状況がさらに悪くなります。
Feature flagsはReactチームにその瞬間を制御する能力を与えます。 code を配信し、休眠状態に保ち、後でどのユーザーがそれを見るかを決定することができます。そのため、リリース作業はすべてまたは何もかからないイベントから、制御されたオペレーションに変わります。
デプロイメントとリリースは異なる仕事です。
デプロイメントは「code がプロダクションにありますか?」という答えをします。リリースは「この行動を今すぐ誰が実行できますか?」という答えをします。
その区別は、リアルなトラフィックを持つReactアプリ、複数の環境を持つアプリ、収益、パーミッション、ナビゲーションを扱う機能を持つアプリの場合に重要です。チームは早期にマージし、内部コホートでプロダクションでテストし、信頼できる行動が得られるまでアクセスを拡大することができます。 Capacitor アプリ、Electronアプリ、ストアでレビューされたモバイルビルドなどのスローピースリリースプラットフォームの場合、その制御はさらに価値があります。ユーザーの手元にすでにバイナリが存在している場合、すべてのユーザーに適したものになるまでの時間が必要です。
フラグは、常に起こる3つの状況で役立ちます:
- 制御されたロールアウト: __CAPGO_KEEP_0__を小規模のグループに最初に公開する新しいパスを表示する
- Experimentation: __CAPGO_KEEP_0__を個別にデプロイしながらバリアントを比較する
- Quick Shutdown: リスクのある機能を無効にするには、ビルドの新しいバージョンを待たずに
A simple rule works well here. If a production issue would be expensive to reverse, ship that code behind a flag.
UI条件付きで停止するのではなく、チームが旗に慣れると、旗のUIに止まることが多い。 flag ? <NewUI /> : <OldUI /> __CAPGO_KEEP_0__は、操作上の価値はあるが、実際の価値は運用上にある。リモート設定、決定論的ターゲット、機能を迅速に無効にする能力が旗が生産環境で役立つのはそれらである。 Capacitorアプリ用のリモート設定プラグイン __CAPGO_KEEP_0__のリリース管理モデルに適合する
旗が役に立たなくなるときは誰も旗に信頼していないときである
__CAPGO_KEEP_0__の成長するフロントエンドコードベースで同じ失敗パターンを観察している。チームが旗を迅速に追加し、環境間で名前のドリフトが発生し、フォールバック値が設定ミスを隠し、誰も「オン」が全体的にオン、スタッフ用にオン、またはステージング用にオンを意味しているか分からなくなったとき、旗システムはリスクを減らすのではなくリスクを生み出すようになる。
安全性は役立ちますが、問題の全体を解決するものではありません。チームは、明確なレジストリ、所有権、UIのフラグ評価方法の統一が必要です。そうでないと、Reactコンポーネントはロールアウト状態についてローカルな仮定を立て、リリースや部分ロールバックの際にそれらの仮定が破綻します。
の差は簡単にわかります:
| 使用例 | 弱いバージョン | 強いバージョン |
|---|---|---|
| UIの切り替え | コンポーネントのローカル状態内に存在するブール値 | 所有権とロールアウトルールを持つリモートフラグ |
| リリースの安全性 | マニュアルデプロイロールバック | リモート設定を通じて即時無効化 |
| 実験 | アドホックブランチ比較 | 安定したコホート割り当てと測定可能な露出 |
重要な心の向きは簡単です。 React の機能フラグは、JSX だけではなく、リリースプロセスに属するものです。そう扱うことをお勧めします、特に、新しいビルドを配信するのが遅く、そして、生産が混乱すると、爆発半径を減らすことのできる、数少ないツールになります。
React アプリの機能フラグのアーキテクチャ
アーキテクチャの決定は、最初のフラグよりも重要です。ランダムなコンポーネントにフラグを直接接続すると、重複したロジック、ロード中のフリッカー、そして、誰もが信頼できる真実の元を知ることができないコードベースが生まれます。
ランタイム プロバイダーを使用せよ、散在した条件分岐を避けよ
React アプリの場合、信頼できるアプローチは、フラグを「ランタイム データ」として扱うことです。サーバー上でまたはローカル キャッシュ内でフラグを評価すること、コホート割り当てを決定論的に保存すること、そして、ユーザーが最初に間違ったデフォルトを表示しないようにするために、反映保護を使用して、最終的な UI ステートをハイドレーション前にレンダリングすることを推奨する React のフラグ メソッドロジーが 3 つあります。 これは、__CAPGO_KEEP_0__ の場所を変えることです。アプリのルート近くにフラグのロードを配置し、消費を簡素化してください。葉のコンポーネント内でフラグを取得するのを避けよ。. Guidance for React flagging recommends three things: evaluate flags on the server or in a local SDK cache, persist cohort assignment deterministically, and render the final UI state before hydration or use anti-flicker protection so users don’t see the wrong default first (__CAPGO_KEEP_0__).
code
__CAPGO_KEEP_0__
- メインツリーがレンダリングされる前に、フラグをロードまたはハイドレーションしてください。
- プロバイダーを通じて公開してください。
- 1 つのハックまたは 1 つのラッパーペターを通じて読み取ってください。
- プレゼンテーショナル コンポーネントの評価ロジックを保ちましょう。
アプリ全体の設定やフラグのためのリモート設定層が必要な場合、Hybrid React アプリで自然に合わせることができるツールとして「__CAPGO_KEEP_0__ リモート設定プラグイン」が必要です。 Capacitor リモート設定プラグイン React Context とカスタムハックを使用したパターン 1
一般的に推奨するデフォルトのパターンです。テストしやすく、後でベンダーを切り替える場合に簡単に移行できるためです。
使用方法は面白くありませんが、これが望ましい結果です。
import React, { createContext, useContext, useMemo } from 'react';
type FlagValue = boolean | 'control' | 'variant-a' | 'variant-b';
type Flags = {
newCheckout: boolean;
checkoutExperiment: FlagValue;
deleteTaskEnabled: boolean;
};
const defaultFlags: Flags = {
newCheckout: false,
checkoutExperiment: 'control',
deleteTaskEnabled: false,
};
const FeatureFlagContext = createContext<Flags>(defaultFlags);
export function FeatureFlagProvider({
flags,
children,
}: {
flags: Flags;
children: React.ReactNode;
}) {
const value = useMemo(() => flags, [flags]);
return (
<FeatureFlagContext.Provider value={value}>
{children}
</FeatureFlagContext.Provider>
);
}
export function useFeatureFlag<K extends keyof Flags>(key: K): Flags[K] {
return useContext(FeatureFlagContext)[key];
}このパターンは、コンポーネントが最終的な答えを求めるだけなので、機能します。答えがどのように計算されたかは気にしません。
function DeleteTaskButton() {
const enabled = useFeatureFlag('deleteTaskEnabled');
if (!enabled) return null;
return <button>Delete task</button>;
}高階関数を使用したパターン 2
__CAPGO_KEEP_0__
より高階のコンポーネント gateする必要がある画面全体、ルート要素、またはレガシークラスコンポーネントの場合、便利です。hook呼び出しをここに追加する必要はありません。 使用方法:
import React from 'react';
import { useFeatureFlag } from './FeatureFlagProvider';
export function withFeatureFlag<P>(
flagKey: 'newCheckout' | 'deleteTaskEnabled',
Fallback?: React.ComponentType<P>
) {
return function wrap(Component: React.ComponentType<P>) {
return function FeatureFlaggedComponent(props: P) {
const enabled = useFeatureFlag(flagKey);
if (!enabled) {
return Fallback ? <Fallback {...props} /> : null;
}
return <Component {...props} />;
};
};
}欠点は、間接性です。モダンなReactでは、Hooksはトレースしやすくなりますが、HOCは開発ツールのコンポーネントツリーを汚染する可能性があります。ただし、ルートレベルでのゲーティングの場合、綺麗です。
const CheckoutPage = () => <div>New checkout</div>;
const LegacyCheckoutPage = () => <div>Legacy checkout</div>;
export default withFeatureFlag('newCheckout', LegacyCheckoutPage)(CheckoutPage);コンポーネントがロールアウトポリシーを決定するのを許可しないでください。コンポーネントはフラグの結果を受け取り、バケット化、ユーザー対象化、キャッシュリフレッシュルールを実装するのではなく、フラグを消費するようにしてください。
React機能フラグパターン比較
基準
| コンテキスト+Hook | より高階のコンポーネント(HOC) | ベストケース |
|---|---|---|
| コンポーネントレベルでの決定とバリアント | __CAPGO_KEEP_0__ | フルページ、ルート、またはレガシーコンポーネントをwrapする |
| 柔軟性 | 高 | 開発者エクスペリエンス |
| モダン機能コンポーネントでは強い | フックが不便な場合に便利 | バンドル明確性 |
| 明確なインポートと直接的な読み取り | 木構造におけるより多くの抽象化 | テスト |
| プロバイダーを介して簡単にモックできる | __CAPGO_KEEP_0__ | __CAPGO_KEEP_0__ |
| 長期のメンテナンス性 | 通常は__CAPGO_KEEP_0__ | __CAPGO_KEEP_0__の場合も問題ありません |
Capgoを使用してReactの機能フラグを実装する場合は初めての場合は Context + Hook. HOCを追加するのは、wrapper-styleのゲーティングの特定のニーズがある場合のみです。
RolloutとRollback戦略の実装
リリース後、機能が不正動作した場合のロールアウト計画は最も重要です。UIでは新しいボタンや画面のみが表示されるかもしれませんが、決定すべきことは、最初に誰がそれを見るか、露出の速度がどれくらいか、そして待って再デプロイすることなく停止できるかということです。
パーセンテージロールアウトには固定割り当てが必要です
パーセンテージロールアウトは割り当てが安定している場合にのみ機能します。同じユーザーが1回の訪問で新しいチェックアウトを、次の訪問で古いチェックアウトを取得した場合、サポートは問題を再現できず、分析はノイズが増し、ユーザーは信頼を失います。
簡単な解決策があります。安定した識別子にフラグキーを加えた決定論的ハッシュでユーザーを分類します。ユーザーIDは通常正しい入力値です。匿名セッションでは、インストールIDまたはデバイスIDを使用できます。 Math.random() ブラウザ内ではユーザーを予測不能的に再割り当てするため、間違ったツールです。
実用的なロールアウトパスは次のようになります。
- 内部ユーザーとQAから始めます。
- 小規模なコホートにリリースします。
- エラー率、変換率の影響、サポートチケットを確認した後、意図的に段階的に拡大します。
- フラグの全生涯で割り当てを固定してください。
最後の点は、容易に過小評価されることがあります。ステキなコホートは、実験のみにとどまらず、インシデント対応を速めるため、エンジニアが即座に基本的な質問に答えることができます:どのユーザーが影響を受けたか?
実験を実行する場合は、サイズを事前に確認してください。Optimizelyのサンプルサイズ計算ツールは、トラフィックボリューム、ベースライン変換率、最小検出効果が必要なユーザー数を変化させる方法を示しています。サンプルサイズ計算ツールOptimizely
ブラウザ外のステージドアップデートの参考資料 Capacitorのライブアップデートの段階的なロールアウト. そのリリースの規則は、パッケージ化されたシェル内でReactアプリが実行されている場合でも、バイナリのロールバックが遅いために適用される。
ターゲットされたリリースとリングベースのリリースは、爆発半径を減らす
特定の機能は、ランダムなパーセンテージで始めるべきではない。請求フロー、承認のプロンプト、データの移行、ユーザーをロックアウトする可能性のあるものは、ターゲットされたリリースで最初に実行する必要がある。
ターゲットが機能するのは、最初の対象者が既知の特性で定義されている場合に限る。
- 内部スタッフのためのドッグフード
- ベータテスターが粗いエッジに同意したもの
- 特定のアカウントの階層
- 法律または言語の要件が異なる地域
- 機能を安全にサポートするデバイスまたはアプリのバージョン
リングベースのリリースは、ターゲットがより実行可能になる。リング0は従業員。リング1は信頼できる外部テスター。後続のリングは、信頼性が向上するにつれて露出を広げる。この構造は、リスクが明らかに不均等である場合に、すべてのユーザーを1つのプールとして扱うという一般的な間違いを回避する。
このリリースモデルと組み合わせて機能するエンビデッドウォークスルーはこちらです。
__CAPGO_KEEP_0__は機能を停止するためのフラグです
リスクのある機能には、機能フロー全体を停止するためのトップレベルオペレーショナルフラグが必要です。
リリース前に機能スイッチを設計する
- アプリ起動初期段階で評価する
- 最後の安全な値をキャッシュする
- フラグサービスが利用できない場合の安全なデフォルト値を選択する
- 機能を停止すると、サイドエフェクトが止まることを確認する
- インシデントの際にフラグを切り替えることができる人をドキュメントする
ウェブアプリのみの場合、リリースリスクを減らすことができます。モバイルやデスクトップのReactアプリの場合、ミニマムのインシデントとユーザーが修正されたビルドを待つことの差が生まれます。codeがすでにバンドルに含まれている場合、リモートフラグはロールバック戦略の一部になります。
機能フラグのテスト、観察性、フラグの負債管理
機能フラグの簡単な部分は、1つを追加することです。高価な部分は、多くのフラグが存在し誰もそのうちのどれがまだ重要かを覚えていない時から始まります。
すべてのフラグは、信頼する必要がある状態を乗算します。
マーティン・フォラーズの警告はまだ有効です:機能フラグが存在すると、チームは両方の __CAPGO_KEEP_0__ 、そして __CAPGO_KEEP_1__ 状態を検証する必要があります。複数のフラグがある場合、可能な状態の組み合わせは組合せ論的に増加し、バグのリスクが高まります。マーティン・フォラーズによる機能トグルに関する話).
これは、React アプリケーションに直接影響します:
- 条件付きレンダリングのパスは急速に広がります: 1 つのページには、誰も気づく前に複数のBranchが存在します。
- hydrationの不一致が起こしやすくなります: クライアントとサーバーが評価のタイミングが悪い場合に異議を唱えることができます。
- 単独では、スナップショットテストはあまり役に立たなくなります: ハッピーパスレンダリングでは、反対のフラグ状態がテストされていない場合、ほとんどの情報が得られません。
実用的テストスタックは次のようになります:
- 評価ロジックのユニットテストを行ってください。
- コンポーネントテストでキーフラグ分岐をテストしてください。
- リスクのあるパスのみのエンドツーエンドカバレージを追加してください。
- デフォルトのフォールバックを明示的に検証してください。
すべての組み合わせを目指すのではなく、ユーザーに害を及ぼす可能性のある状態やレイアウトを破壊する可能性のある状態だけをテストしてください。
フラグの負債は実際に存在し、静かに高額になることがあります。
Old flags become a form of code rot. They stay in conditionals, comments, dashboards, and runbooks. Then someone edits the “temporary” branch months later because nobody removed it.
実践で機能するクリーンアップルールは単純です:
| 問題 | 何をするか |
|---|---|
| 所有者なし | 旗が作成されたときにチームまたは人を割り当てる |
| 終了状態なし | 旗が削除、保持、またはconfigに変換されるかどうかを決定する |
| 旗があまりにも多くの制御を行っている | 旗を小さく、狭い旗に分割する |
| 旗の背後にあるコアロジックが隠されている | ビジネスロジックをレンダリング条件分岐から外す |
クリーンアップルール: 旗には1日以内に所有者、目的、削除計画が必要です。
この問題は、チームが「信頼」問題に陥る場所でもあります。旗名は存在しますが、フォールバックが間違っています。ダッシュボードエントリが変更されたが、アプリタイプが変わっていません。codeパスは死んでいるが、まだアクセス可能です。そのため、タイプ生成とレジストリ検証は、大規模システムでは、初期実装が簡単に見えていても重要です。
観測性は、旗が成功したか、単に存在したかを教えてくれる。
ロールアウトは、旗が完全に露出したときに完了していない。チームが何が起こったかを知るまで完了していない。
少なくともこれらの質問を追跡する:
- 露出: どのユーザーがどのバリアントを視認したか?
- エラー: 旗付けられたパスがクライアントサイドのエラーを引き起こしたか?
- 採用: ユーザーが公開された機能を使用したか?
- ロールバック信号: どの閾値が旗をオフにするのに十分か?
旗のプラットフォームがその質問に答えられない場合、リリースレビュー中はまだ推測することになる。
CI/CDによる旗と自動化
不正なデプロイは明らかです。旗の変更は、静かに、そして場合によっては危険なものです。なぜなら、codeの同様のレビュー経路を通らなくても、生産性の変更が行われるからです。
生産性の変更と同様に旗の変更を扱う
旗はリリースの制御です。チームが生産性の旗を切り替えられる場合、そのチームはユーザーが受け取るもの、codeのパスが実行されるもの、そして時々、統合が発火するものを変更できます。これは、デプロイアクセスの同様の規制を必要とします。
最小限の制御は簡単です:
- ロールベースのアクセス制御: 生産性の旗の変更を制限し、読み取りアクセスと編集アクセスを分離する。
- 監査ログ: 旗の変更を誰がいつ変更したか、どの環境を変更したかを明確に記録する。
- 環境隔離: ステージング、プレビュー、生産性の旗は区別されるべきであり、テスト変更がライブトラフィックに影響しないようにする。
- サーバーサイドのチェックは敏感な決定に使用しないでください: クライアントフラグはUIを非表示にすることができますが、請求アクセス、特典、または認証に影響を与えるべきではありません。
フラグダッシュボードを共有スプレッドシートのように扱うのはよくない習慣です。製品は顧客に機能を有効にすることができます。サポートは不満を止めるために機能を無効にすることができます。エンジニアは機能が変更されていないと考えます。なぜなら、デプロイがなかったからです。そのような設定は、インシデントを説明する必要があるまで機能します。
バンドルアプリはリスクを高めます。Webアプリでは、codeの修正が迅速に実行できます。Capacitorまたはデスクトップアプリでは、既にデバイスに置かれている破損したcodeが、リモートフラグによって暴露される可能性があります。codeを使用してReactモバイルアプリを構築しているチームは、承認ルールについてさらに厳格になります。ロールバックは、機能を無効にするのではなく、バイナリを置き換えるのではなく、実行済みの機能を無効にすることが多いためです。 React mobile apps with Capacitor フラグが外部のデリバリープロセスから独立している場合、信頼性が低くなります。安全なパターンは、機能を配信するワークフローとともに管理することです。
通常、次のことが必要です:
機能__CAPGO_KEEP_0__とともにPRを作成または更新する
CIでリモートレジストリとタイプ付きフラグ定義を検証する
- Create or update flags in the same PR as the feature code
- __CAPGO_KEEP_0__はCapacitorのことです。
- __CAPGO_KEEP_1__はCapacitorのことです。
- 必要なフラグが欠落または不正設定の場合、リリースをブロックします。
- 期限切れのフラグやロールアウトの終了状態を持つフラグのクリーンアップタスクをスケジュールします。
私は単純なルールを好みます: 製品インシデントがフラグによって引き起こされる可能性がある場合、CIはリリース前にセットアップを検知できるようにする必要があります。そのうちのいくつかは、欠落したデフォルト値、キーの名前変更、古い環境マッピング、codeに存在するがコントロールプレーンに存在しないフラグです。
パイプライン構造のスターティングポイントが必要な場合、 Git Action CI/CD ワークフロー ビルドチェック、デプロイゲート、フラグ検証のための自動化ステップを拡張できるため、ビルドチェック、デプロイゲート、自動化ステップのための良い参照です。
シークレットとSDKの選択肢を面白くしないでください。
フロントエンドチームはフラグのセキュリティを過度に複雑にし、明らかな部分を無視することがよくあります。ブラウザで設計された一般的なクライアントサイドSDKキーは、通常問題ありません。管理トークン、書き込みクレデンシャル、環境管理キーはCIまたはバックエンドサービスのみに属します。
実用的には、単純です。プレゼンテーション変更や低リスクの実験にはクライアントサイド評価を使用し、価格、許可、敏感なフローのキルSwitch、またはローカルJavaScriptに信頼できないものはサーバーサイド評価を使用します。
この境界は、スローミリシング環境ではより重要です。Webチームは迅速なデプロイで回復できます。モバイルおよびデスクトップチームは、フラグシステムが回復メカニズムである必要があります。間違った人がプロダクションフラグを編集できる場合、またはCIがフラグ契約を検証しない場合、ロールバックは迅速に混乱します。
Capacitor
Most articles about react feature flags assume a web app that can redeploy instantly. That assumption breaks the moment your React code lives inside Capacitor, ReactElectron
Bundled apps change the release math
In hybrid apps, you often ship JavaScript, CSS, assets, and config inside a bundle that users won’t update immediately. A feature might already be on-device before you want anyone to use it. That changes the role of flags completely.
A recent discussion around hybrid release strategy pointed out that existing React flag content rarely addresses the release-risk model for Capacitor or Electron apps. For those teams, the primary need is a release orchestration layer that combines flags, targeted channels, and rollback protection instead of a simple on/off switch, especially when avoiding store review delays matters (hybrid app release-risk discussion).
hybridアプリのリリースリスクの議論 remote activation of already shipped capability.
hybridアプリのリリースリスクの議論
This is also why channel-based distribution matters. If you’re building hybrid apps and need the app shell plus web code release model to make sense together, ハイブリッドアプリを構築し、Web Capacitor リリースモデルとアプリシェルを組み合わせる必要がある場合、 Reactモバイルアプリを作成するには__CAPGO_KEEP_0__
は実用的な開始点です。
For mobile and desktop teams, flags alone won’t solve every release problem. They can hide or enable code paths, but they can’t replace shipping fixed assets or logic when the bug is already in the bundle.
モバイルとデスクトップチームにとって、フラグだけではすべてのリリース問題を解決することはできません。
- deliver code updates outside full store cycles when your platform allows it,
- より強力なモデルは次のとおりです。
- プラットフォームが許可する場合、__CAPGO_KEEP_0__ アップデートをフルストアサイクル外で配信することです。
チャネルまたはアウディエンスにターゲットを絞ります。
If your team ships Capacitor or Electron apps and needs that release-control layer, Capgo は、特定のチャネルに署名されたWebバンドルを配信し、ロールバック保護と観察性をサポートし、機能フラグがライブ更新と共に機能する必要があるハイブリッドアプリワークフローに適合するオプションです。
__CAPGO_KEEP_0__
を使用している場合 __CAPGO_KEEP_0__ を使用してチャネルルーティングとステージドロールアウトを計画し、を連携してください。 チャンネル チャンネル チャンネル チャンネル ベータテストソリューション __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ ベータテストソリューションにおける製品ワークフローについて、 バージョン対象ソリューション バージョン対象ソリューションにおける製品ワークフローについて。
