環境ベースのフィーチャーフラグ

環境ベースのフィーチャーフラグ

環境ベースのフラグを使用すると、本番環境に影響を与えることなく、開発やステージングで機能を有効にできます。これは新機能を実際のユーザーに届ける前に安全にテストするために不可欠です。

設定例

{
  "new-search-algorithm": {
    "name": "New Search Algorithm",
    "description": "SQL LIKEクエリを置き換えるElasticsearchベースの検索",
    "type": "boolean",
    "enabled": true,
    "defaultValue": false,
    "targeting": [
      {
        "type": "environment",
        "environment": "development"
      },
      {
        "type": "environment",
        "environment": "staging"
      }
    ]
  }
}

マルチ環境戦略

典型的な環境プロモーションフロー：

Development（常にオン）
    ↓
Staging（QAテスト用にオン）
    ↓
Production（オフ、その後段階的ロールアウト）

LaunchDarkly環境

LaunchDarklyは環境ごとのフラグ状態をネイティブサポートしています。各環境には独自のターゲティングルールがあります：

{
  "environments": {
    "development": { "on": true, "fallthrough": { "variation": 0 } },
    "staging": { "on": true, "fallthrough": { "variation": 0 } },
    "production": { "on": false, "offVariation": 1 }
  }
}

一般的なパターン

パターン	説明
開発優先	開発で有効化、ステージングに昇格、その後本番へ
本番専用	本番の動作を制御するためにのみフラグが存在
環境固有設定	環境ごとに異なる値（例：API URL）
テストオーバーライド	QAがステージングで任意のフラグを有効化可能

ベストプラクティス

• 環境名をハードコードしない。SDKのコンテキスト/属性システムを使用する
• 最終検証用の「プリプロダクション」環境の検討
• 環境間で異なることが予想されるフラグを文書化する
• フラグ依存関係を使用して前提条件フラグも有効であることを確認する