機能フラグ

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

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

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

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

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

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

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

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

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