機能を完成させたあなたは、プルリクエストはきれいだ。QAは「良さそう」と言っている。でも、全員に一度に配信したくない。
That feeling is usually the first sign that your React app has outgrown simple deploys. Once a product has real users, a release stops being just a technical event. It becomes a risk decision. If the new search UI breaks, if the checkout variant confuses users, or if a mobile build ships code you can’t quickly undo, you need more than if (process.env.NODE_ENV) 機能フラグは、機能を個別に配信するためのリリース制御層として機能します。機能フラグを使用すると、機能を配信する前に、機能が正常に動作することを確認できます。
機能フラグは、機能を個別に配信するためのリリース制御層として機能します。機能フラグを使用すると、機能が正常に動作することを確認できます。 機能フラグは、機能を個別に配信するためのリリース制御層として機能します。機能フラグを使用すると、機能が正常に動作することを確認できます。 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アプリケーションに機能フラグを設計する
- ロールアウトとロールバック戦略の実装
- テスト観測性とフラグ負債の管理
- CI/CDを自動化して旗を保護する
- CapacitorとモバイルアプリのWeb機能フラグの超え
モダンなReactアプリの旗フラグは不可欠
金曜日の午後、新しい請求明細UIはすでにデプロイ済み、サポートはリリースチェックリストを開いているが、1つのエンタープライズクライアントは月曜まで古いフローを必要としている。ウェブアプリではすでに緊張感が高まっている。デスクトップインストーラーやモバイルストアから配信されるバンドルされたReactアプリでは、ロールバックが数分から数時間かかるのではなく、数時間から数日かかる
Feature flags give React teams control over that moment. They let you ship the code, keep it dormant, and decide later which users should see it. That changes release work from an all-or-nothing event into a controlled operation.
__CAPGO_KEEP_0__のデプロイとリリースは異なるタスクです。
codeは「生産環境にcodeが存在するか？」と答える。リリースは「この行動を実行できるのは誰ですか？」と答える。
実際のトラフィック、複数の環境、収益、権限、ナビゲーションに関わる機能を持つReactアプリでは、その区別が重要になります。チームは早期にマージし、内部コホートで生産環境でテストし、機能を信頼するまでアクセスを拡大することができます。Capacitorアプリ、Electronアプリ、ストアでレビューされたモバイルビルドなどのリリース速度が遅いプラットフォームでは、その制御はさらに貴重です。なぜなら、機能が全員に適合するまでに、バイナリはすでにユーザーの手元にある可能性があるからです。
フラグは、常に起こる3つのシナリオで役に立ちます。
- 制御されたロールアウト: 小さなグループに新しいパスを公開する
- 実験: バリアントを比較することなく、別々のデプロイを維持することなく
- 急いでシャットダウン: リスクのある機能を無効にすることなく、新しいビルドを待たなくても
ここでは、生産問題を逆転させるコストが高額であれば、codeをフラグで保護するという単純なルールが効果的です。
フラグのUI条件付きを止まるチームは、新しいチームです。 flag ? <NewUI /> : <OldUI /> は、見える部分ですが、興味のある部分ではありません。 そのコア価値は、運用です。リモート設定、決定論的ターゲット設定、および機能を迅速に停止できる機能が、旗が生産環境で役に立つのはなぜか、旗が役に立つのはなぜかです。 また、Reactアプリがアプリ全体の実行時設定も必要な場合、 リモート設定プラグインはCapacitorアプリ用です リリース管理モデルに合致します。
旗が役に立つのは、誰も旗を信頼していない時点です
成長するフロントエンドコードベースで同じ失敗パターンを観察しています。 チームは旗を迅速に追加し、環境間で名前がずれ、デフォルト値が設定ミスを隠し、誰も「オン」が意味するか、全体的にオン、スタッフ用にオン、またはステージングでオンのみを意味するかを把握していません。 その時点で、旗システムはリスクを減らすのではなく、リスクを生み出します。
型安全性は役に立つですが、問題の全てを解決するものではありません。 チームは依然として明確なレジストリ、所有権、旗をアプリ全体で評価するための一貫した方法が必要です。 そうしないと、Reactコンポーネントはロールアウト状態についてローカルな仮定を立て、ロールアウトや部分的なロールバックの際にそれらの仮定が破綻します。
違いは簡単に認識できます。
| 用途 | 弱いバージョン | 強いバージョン |
|---|---|---|
| UI切替 | コンポーネントのローカルブール値 | リモートフラグの所有権とロールアウトルール |
| リリースの安全性 | マニュアルデプロイロールバック | リモート設定を通じて即時無効化 |
| 実験 | アドホックブランチの比較 | 安定したコホートの割り当てと測定可能な露出 |
重要な心の変化は単純です。Reactの機能フラグはリリースプロセスに属します。JSXだけではありません。特に、ビルドを出荷するのが遅いアプリでは、リリースプロセスに合わせてそう扱うことをお勧めします。そうすることで、生産性が低下したときに、爆発半径を最小限に抑えることができる唯一のツールになります。
Reactアプリの機能フラグのアーキテクチャ
アーキテクチャの決定は最初のフラグよりも重要です。ランダムなコンポーネントにフラグを直接接続すると、重複したロジック、ロード中のフリッカー、誰もが信頼できるソースを知らないコードベースが生まれます。
ランタイムプロバイダーを使用するのではなく、散在した条件分岐を使用しない
Reactアプリの場合、信頼できるアプローチはフラグをソースとして扱うことです 実行時データ. React フラグのガイドラインでは、以下の 3 つのことを推奨しています:サーバーまたはローカル SDK キャッシュでフラグを評価する、コホート割り当てを決定論的に保存する、そして、ユーザーが間違ったデフォルトを最初に見ないように、ハイドレーションまたはアンチフリッカー保護の前に最終 UI ステートをレンダリングする (React フラグの方法論).
フラグのロードの場所が変わる。アプリのルート近くに code を置く。フラグの消費を簡単にする。葉のコンポーネント内でフラグをフェッチしない。
実践的な形は以下のようになります:
- フラグをロードまたはハイドレートする前に、主な木がレンダリングされる。
- プロバイダーを通じて公開する。
- 1 つのホックまたは 1 つのラッパーペターニングを通じて読み取る。
- プレゼンテーショナル コンポーネントから評価ロジックを外す。
アプリ全体の設定やフラグのためのリモート設定層が必要な場合は、 Capacitor リモート設定プラグイン ハイブリッド React アプリで自然に合わせることができるツールです。
__CAPGO_KEEP_0__
React Contextとカスタムフックを使用したパターン
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>;
}使用方法は面白くないが、これが望ましい結果です。
このパターンは、コンポーネントが最終的な答えを要求するだけなので、よく機能します。答えがどのように計算されたかは気にしません。
__CAPGO_KEEP_1__ __CAPGO_KEEP_2__ __CAPGO_KEEP_3__
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} />;
};
};
}__CAPGO_KEEP_4__
const CheckoutPage = () => <div>New checkout</div>;
const LegacyCheckoutPage = () => <div>Legacy checkout</div>;
export default withFeatureFlag('newCheckout', LegacyCheckoutPage)(CheckoutPage);__CAPGO_KEEP_5__
__CAPGO_KEEP_6__
__CAPGO_KEEP_7__
| Criterion | Context + Hook | Higher-Order Component (HOC) |
|---|---|---|
| Best use case | Component-level decisions and variants | Wrapping full pages, routes, or legacy components |
| Flexibility | High | Medium |
| Developer experience | Strong in modern function components | Useful when hooks are awkward |
| 明確な構造 | 明確なインポートと直接的な読み取り | 木構造におけるより多くの抽象化 |
| テスト | プロバイダーを通じて簡単にモックできる | ラッピングされた統合ケースに対して簡単 |
| 長期的なメンテナンス性 | 通常は良い | sparingly使用する場合 |
Capgoを使用してReactの機能フラグを実装する場合、最初は コンテキスト+フック特定のラッパースタイルのゲーティングの必要性がある場合にのみHOCを追加する
リリース後の機能の不正動作の際にロールアウトとロールバック戦略を実装する
機能フラグのロールアウトとロールバック戦略のためのファンルーム図
パーセンテージロールアウトは、割り当てが安定している場合にのみ機能します。同じユーザーが新しいチェックアウトに訪問し、古いチェックアウトに訪問した場合、サポートは問題を再現できず、分析はノイズが増し、ユーザーは信頼を失います。
問題の解決は簡単です。ユーザーを安定した識別子とフラグキーに基づいて決定論的なハッシュでバケット化します。ユーザーIDは通常の入力になります。匿名セッションでは、インストールIDまたはデバイスIDを使用できます。
ブラウザ内では、ユーザーを予測不能に再割り当てするため、間違ったツールです。 Math.random() 実用的ロールアウトパスは次のようになります。
内部ユーザーとQAから始めます。
- 小規模なコホートにリリースします。
- エラー率、変換影響、サポートチケットの確認後に意図的なステージで拡大します。
- フラグの全生涯で割り当てを固定にします。
- A funnel diagram illustrating rollout and rollback strategies for software feature flags from internal to global release.
That last point is easy to underestimate. Sticky cohorts are not just for experiments. They make incident response faster because engineers can answer a basic question immediately: which users were exposed?
実際には、エクスペリメントのためのものだけではない。インシデント対応が速くなるため、エンジニアは即座に、どのユーザーが影響を受けたかという基本的な質問に答えることができる。If you do run experiments, size them before you ship. A sample size calculator from Optimizely shows how traffic volume, baseline conversion, and minimum detectable effect change the number of users you need per variant (実際にエクスペリメントを実行する場合、リリースする前にサイズを調整する。Optimizelyのサンプルサイズ計算ツールは、トラフィックの量、基準変換率、最小検出可能効果が、各バリアントあたりの必要なユーザー数をどのように変化させるかを示しています。
Optimizely sample size calculator phased rollouts for Capacitor live updates. Without that check, teams often read noise as signal and promote a feature too early.
チェックがなければ、チームはノイズを信号と見なし、機能を早すぎるまでに推進することになる。
A useful reference for staged updates outside the browser is
ブラウザ外での段階的な更新のための参考資料は
- phased rollouts for __CAPGO_KEEP_0__ live updates
- 段階的なロールアウトのための__CAPGO_KEEP_0__ライブ更新のための参考資料は
- __CAPGO_KEEP_0__
- 特定アカウントの階層
- 法的または言語上の要件が異なる地域
機能を安全にサポートするデバイスまたはアプリのバージョン
リングベースのリリースにより、ターゲットをより実行可能にします。リング0は従業員です。リング1は信頼できる外部テスターです。後続のリングは信頼性が向上するにつれて露出を拡大します。この構造により、チームはリスクが明らかに不均等であるユーザーを一つのプールとして扱う一般的な間違いを避けることができます。
このリリースモデルに合うこの埋め込みウォークスルーをご覧ください。
リスクのある機能には、機能フロー全体を無効にするトップレベルの運用フラグが必要です。
リスクのある機能には、機能フロー全体を無効にするトップレベルの運用フラグが必要です。
- 機能をリリースする前に、キルSwitchを設計する
- アプリ起動の早い段階で評価する
- 最後の安全な値をキャッシュする
- フラグサービスが利用できない場合に安全なデフォルト値を選択する。
- インシデント中は誰がフリップできるかを記録する
ウェブ用アプリではリリースリスクを減らす。モバイルとデスクトップのReactアプリでは、修正されたビルドをユーザーに提供するまでに数日待たされることと、軽微なインシデントの差になる。codeがすでにバンドルに含まれている場合、リモートフラグはロールバック戦略の一部になるのではなく、リリース戦略の一部になる。
テスト観測性とフラグ負債の管理
機能フラグの簡単な部分は1つ追加すること。高価な部分は、多くのフラグが存在し誰もそのうちどれがまだ重要かを覚えていないときに始まる。
各フラグは信頼できる状態の数を倍増させる
マーティン・フラワーの警告は依然として有効である:機能フラグが存在する場合、チームは両方の オン オフ 状態を検証する必要がある。 複数のフラグの場合、可能な状態の組み合わせは組合せ的に増加し、リグレッションリスクを引き起こす。マーティン・フラワーの機能トグルに関する警告).
__CAPGO_KEEP_0__の影響はReactアプリケーションに直接及ぶ:
- 条件付きレンダリングパスは迅速に広がる: 1つのページが複数のbranchを持つことができる:
- hydrationの不一致は容易にトリガーされる: クライアントとサーバーが評価のタイミングが異なる場合に異議を唱えることができる:
- スナップショットテストは単独では役に立たなくなる: ハッピーパスのレンダリングでは、反対のフラグ状態がテストされていない場合、ほとんどの情報が得られない:
実用的テストスタックは以下のようになる:
- 評価ロジックの単体テストを行う:
- コンポーネントテストでキーフラグされたbranchをテストする:
- エンドツーエンドのカバレッジを実施するが、リスクのあるパスのみを対象とする:
- デフォルトのフォールバックを明示的に検証する:
すべての組み合わせを目指すのではなく、ユーザーにダメージを与える可能性のある状態やレイアウトを破壊する可能性のある状態をテストするようにしましょう。
フラグの負債は実際に存在し、安く見えますが、実際には高額になります。
codeの腐敗: 既存のフラグは、条件分岐、コメント、ダッシュボード、実行書類に残り、数ヶ月後誰かが「一時的な」ブランチを編集することになります。
実践で機能するクリーンアップルールは簡単です:
| 問題 | 何をするか |
|---|---|
| 所有者がいない | フラグが作成されたときにチームまたは人を割り当てる |
| 終了状態がない | フラグが削除、保持、または設定に変換されるかどうかを決定する |
| フラグが制御する範囲が広すぎる | それをより小さく、狭いフラグに分割する |
| フラグの背後にあるコアロジックを隠す | レンダリングの条件分岐からビジネスロジックを外す |
クリーンアップルール: フラグには、所有者、目的、廃止計画が最初から存在するはずです。
チームは「信頼」問題に陥ることがあります。フラグ名は存在しますが、フォールバックが間違っている場合、ダッシュボードのエントリが変更されたが、アプリタイプが変わっていない場合、code パスは死んでいるがまだアクセス可能な場合、そのため、タイプ生成とレジストリ検証は大規模システムでは重要です。最初の実装が単純に見えた場合でも。
観察性は、フラグが役に立ったか、ただ存在したかを教えてくれる
ロールアウトは、フラグが完全に露出した時点で完了しない。完了するのは、チームが何が起こったかを知る時点である
少なくともこれらの質問を追跡する
- 露出 どのユーザーがどのバリアントを見たか
- エラー フラグされたパスがクライアントサイドのエラーを引き起こしたか
- 導入: ユーザーが公開された機能を使用したかどうか?
- ロールバック信号: どの閾値が機能をオフにするのに十分か?
フラグプラットフォームが回答しない場合、リリースレビュー中でも推測することになります。
CI/CDを使用したフラグのセキュリティと自動化
悪いデプロイは明らかです。悪いフラグの変更は、静かに、そして場合によっては危険です。なぜなら、codeのパスを変更し、同じレビューのパスを通らなくても、生産的な動作を変更するからです。
フラグの変更を生産的な変更と同じように扱う
機能フラグはリリースの制御です。チームが生産環境でフラグを切り替えられる場合、そのチームはユーザーが受け取るもの、codeのパスを実行するもの、そして場合によっては、どの統合が発火するかを制御できます。そのような権限はデプロイアクセスと同じ規制が必要です。
最小限の制御は簡単です:
- ロールベースのアクセス制御: 生産フラグの変更を許可する人を制限し、読み取りアクセスと編集アクセスを分離する。
- 監査ログ： フラグの変更を記録するには、変更した人、変更した時刻、変更した環境を明確に記録する。
- 環境隔離： ステージング、プレビュー、生産フラグは異なるものでなければなりません。テスト変更が実行中のトラフィックに影響しないようにするためです。
- 機密情報の決定に影響を与えるサーバーサイドチェック： クライアントフラグはUIを隠すことができますが、請求アクセス、特権、認可にはなりません。
フラグダッシュボードを共有スプレッドシートのように扱うのはよくない習慣です。製品は顧客に機能を有効にします。サポートは不満を止めるために機能を無効にします。エンジニアはデプロイがなかったので誰も変更していないと考えます。その設定は、インシデントを説明する必要があるまで機能します。
バンドルアプリはリスクを高めます。Webアプリでは、codeの修正が迅速に配信できます。Capacitorまたはデスクトップアプリでは、既にデバイスに置かれている破損したcodeが待っている可能性があります。codeでReactモバイルアプリを構築しているチームは、承認ルールを厳しくする必要があります。ロールバックは、既に配信された機能を無効にするのではなく、バイナリを置き換える必要があるためです。 React mobile apps with Capacitor __CAPGO_KEEP_0__
__CAPGO_KEEP_1__
旗は、配信プロセス外に存在する場合、信頼できなくなる。安全なパターンは、機能を配信するワークフローと同様に管理することである。
通常は次のようになる。
- 機能とともにPRを作成または更新し、codeを含める。
- CIでリモートレジストリとタイプ付きフラグ定義を検証する。
- 環境ごとにデフォルト値を意図的に設定する。
- 必要なフラグが欠落しているか、不正に設定されている場合にリリースをブロックする。
- 期限切れ日付またはロールアウト終了状態を持つフラグのクリーンアップタスクをスケジュールする。
生産事故がフラグによって引き起こされる可能性がある場合、CIはリリース前にセットアップを検出できるようにするべきだという簡単なルールを私は好む。その中に含まれるものは、欠落しているデフォルト値、キー名の変更、古い環境マッピング、codeに存在するがコントロールプレーンに存在しないフラグなどである。
パイプライン構造のスターティングポイントが必要な場合、 Git Action CI/CD ワークフローは、ビルドチェック、展開ゲート、フラグ検証のための自動化ステップを拡張できる固い基盤となる。 シークレットと__CAPGO_KEEP_0__の選択肢を面白くしない
Keep secrets and SDK choices boring
フロントエンドチームは、フラグのセキュリティを過度に複雑にし、明らかな部分を無視することがよくあります。ブラウザで設計された一般的なクライアントサイドのSDKキーは、通常問題ありません。管理トークン、書き込みクレデンシャル、環境管理キーはCIまたはバックエンドサービスのみに属します。
実用的な分割は簡単です。プレゼンテーション変更や低リスクの実験用にクライアントサイドの評価を使用し、価格、許可、敏感なフローにkill switchを使用するなど、ローカルJavaScriptに信頼できないものはサーバーサイドの評価を使用します。
この境界は、スローページング環境ではより重要です。Webチームは迅速なデプロイで回復できますが、モバイルおよびデスクトップチームは、フラグシステムを回復機構として使用する必要があることがよくあります。プロダクションフラグを間違った人々が編集できる場合、またはCIがフラグ契約を検証しない場合、ロールバックは迅速に混乱することになります。
Capacitorとモバイルアプリ用のWeb機能フラグの超え方
大多数のReact関連の記事は、即座に再デプロイできるWebアプリを前提としています。その仮定は、ReactcodeがElectron、または他のバンドルされたランタイム内に存在する場合にすぐに破棄されます。 Capacitor, ハイブリッドアプリでは、ユーザーがすぐに更新しないように設計されたJavaScript、CSS、アセット、設定を含むバンドルを配信することがよくあります。特定の機能はすでにデバイス上に存在している可能性があります。フラグの役割は完全に変わります。ハイブリッドアプリでは、ユーザーがすぐに更新しないように設計されたJavaScript、CSS、アセット、設定を含むバンドルを配信することがよくあります。特定の機能はすでにデバイス上に存在している可能性があります。フラグの役割は完全に変わります。
Electron
または他のバンドルされたランタイム内に存在する場合にすぐに破棄されます。
最近のハイブリッドリリース戦略に関する議論では、既存のReactフラグコンテンツがElectronアプリやCapacitorのリリースリスクモデルに対処していないことが指摘されました。ハイブリッドアプリリリースリスクに関する議論).
実際にそうです。バンドルされたアプリでは、フラグは条件付きレンダリングよりも 既に配信された機能の遠隔アクティブ化.
モバイルまたはデスクトップのReactアプリでは、フラグはUIの表示よりもリリースタイミングを制御することが多いです。
これはまた、チャンネルベースの配布が重要である理由です。ハイブリッドアプリを開発し、Webcodeリリースモデルとアプリシェルを組み合わせる必要がある場合、 Reactモバイルアプリの作成Capacitor は実用的な開始点です。
フラグは、更新配信と組み合わせることで最も効果的です。
モバイルとデスクトップチームでは、フラグだけではリリースのすべての問題を解決することはできません。既にバンドルされているバグを修正したアセットやロジックを配信する必要があるため、フラグはcodeパスを隠すか有効にすることができます。
より強力なモデルは:
- codeの更新を、プラットフォームが許可する場合、フルストアサイクル外で配信することです。
- target those updates by channel or audience、
- and use flags to control activation、rollback、and staged exposure.
Used together、live updates and flags give hybrid teams something closer to web-style release control. That doesn’t remove the need for discipline. It just gives you more than one lever when something goes wrong.
If your team ships Capacitor or Electron apps and needs that release-control layer、 Capgo is one option to look at. It delivers signed web bundles to targeted channels、supports rollback protection and observability、and fits the kind of hybrid-app workflow where feature flags need to work alongside live updates rather than replacing them.
Keep going from React Feature Flags: A Complete Implementation Guide
If you are using React Feature Flags: A Complete Implementation Guide to plan channel routing and staged rollout、connect it with Channels for the implementation detail in Channels, チャンネル チャンネルの実装詳細について チャンネル チャンネルの実装詳細について ベータテスト ソリューション ベータテスト ソリューションの製品ワークフローについて バージョン ターゲット ソリューション バージョン ターゲット ソリューションの製品ワークフローについて
