機能フラグ

機能フラグをマイクロフロントエンドに実装して、複数の環境で機能のテストとリリースを容易に調整できます。機能フラグ手法は、ブールベースのストアで決定を一元化し、それに基づいて動作を駆動することで構成されます。多くの場合、特定の時点まで非表示にできる変更をサイレントに伝達し、ブロックされる新機能の新しいリリースをロック解除して、チームの速度を低下させるために使用されます。

特定の日付に起動されるマイクロフロントエンド機能に取り組むチームの例を考えてみましょう。この機能は準備完了ですが、個別にリリースされる別のマイクロフロントエンドの変更とともにリリースする必要があります。両方のマイクロフロントエンドのリリースをブロックすると、アンチパターンと見なされ、デプロイ時にリスクが高まります。

代わりに、チームはレンダリング時間中に (おそらく共有特徴量フラグ API への HTTP 呼び出しを通じて) 両方が消費するデータベースにブール機能フラグを作成できます。チームは、ブール値が に設定されているテスト環境で変更をリリースTrueして、本稼働環境に起動する前にプロジェクト間の機能要件と非機能要件を検証することもできます。

機能フラグの使用のもう 1 つの例は、 QueryStringパラメータを使用して特定の値を設定するか、特定のテスト文字列を Cookie に保存することで、フラグの値を上書きするメカニズムを実装することです。製品所有者は、起動日まで他の機能やバグ修正のリリースをブロックすることなく、機能を反復処理できます。指定された日付に、データベースのフラグ値を変更すると、チーム間で調整されたリリースを必要とせずに、変更がすぐに本番環境に表示されます。機能がリリースされると、開発チームはコードをクリーンアップして古い動作を削除します。

その他のユースケースには、コンテキストベースの機能フラグシステムのリリースが含まれます。例えば、1 つのウェブサイトで複数の言語で顧客にサービスを提供している場合、特定の国の訪問者のみが機能を利用できる可能性があります。機能フラグシステムは、国のコンテキストを送信するコンシューマーに依存することができ (HTTP Accept-Language ヘッダーを使用するなど）、そのコンテキストに応じて動作が異なる場合があります。

機能フラグはデベロッパーと製品所有者間のコラボレーションを容易にする強力なツールですが、コードベースの大幅な低下を避けるために、人々の努力に依存しています。複数の機能でフラグをアクティブにしておくと、問題のトラブルシューティング時の複雑さが増し、JavaScript バンドルのサイズが増加し、最終的に技術的負債が蓄積される可能性があります。一般的な緩和アクティビティは次のとおりです。

• フラグの背後にある各機能をユニットテストしてバグの可能性を減らすことで、テストを実行する自動 CI/CD パイプラインに長いフィードバックループを導入できます。

• コード変更中のバンドルサイズの増加を測定するツールの作成。コードレビュー中に軽減できます。

AWS は、Amazon CloudFront 関数または Lambda@Edge を使用してエッジでの A/B テストを最適化するためのさまざまなソリューションを提供します。これらのアプローチは、仮定をアサートするために使用しているソリューションまたは既存の SaaS 製品の統合の複雑さを軽減するのに役立ちます。詳細については、「A/B テスト」を参照してください。