launchdarkly-flag-create

LaunchDarkly フラグの作成と設定

あなたは、コードベースに新しいフィーチャーフラグを導入する作業をガイドするスキルを使用しています。あなたの役割は、このコードベースでフラグがどのように既に使用されているかを調査し、それに適合する形で LaunchDarkly にフラグを作成し、既存のパターンに一致する評価コードを追加し、すべてが正しく接続されていることを検証することです。

前提条件

このスキルを使用するには、リモートでホストされている LaunchDarkly MCP サーバーが環境に設定されている必要があります。

必要な MCP ツール:

• create-flag: プロジェクトに新しいフィーチャーフラグを作成します
• get-flag: フラグが正しく作成されたことを検証します

オプションの MCP ツール (ワークフローを強化):

• list-flags: 既存のフラグを閲覧して、命名規則やタグを理解します
• update-flag-settings: フラグのメタデータ (名前、説明、タグ、一時/永続ステータス) を更新します

ワークフロー

ステップ 1: コードベースを調査する

何かを作成する前に、このコードベースがフィーチャーフラグをどのように使用しているかを理解してください。

1. SDK を見つけます。 LaunchDarkly SDK のインポートまたは初期化を検索します:

   • インポート内で launchdarkly、ldclient、ld-client、LDClient を探します
   • SDK 依存関係について package.json、requirements.txt、go.mod、Gemfile、または同等のものを確認します
   • どの SDK が使用されているかを特定します (サーバーサイド Node、React、Python、Go、Java など)

2. 既存のフラグ評価を見つけます。 このコードベースが使用しているパターンを理解するために、バリエーション呼び出しを検索します:

   • 直接的な SDK 呼び出し: variation()、boolVariation()、useFlags() など
   • ラッパーパターン: このコードベースはフラグをサービスやユーティリティの背後に抽象化していますか?
   • 定数定義: フラグキーはどこかで定数として定義されていますか?
   • 言語ごとのパターンについては SDK 評価パターン を参照してください

3. 規約を理解します。 既存のフラグを見て、以下を学びます:

   • 命名規則: キーは kebab-case、snake_case、camelCase のどれですか?
   • 構成: フラグキーは機能と同居していますか、それとも定数ファイルに集中していますか?
   • デフォルト値: 既存の評価はどのようなデフォルトを使用していますか?
   • コンテキスト/ユーザーの構築: このコードベースは SDK に渡すユーザー/コンテキストオブジェクトをどのように構築していますか? これは、将来のターゲティングが使用できるコンテキストの種類と属性を決定します。また、これはサーフェス (サーバー、クライアント、匿名) によって異なります。ルール、個別ターゲット、またはロールアウトを計画する前に コンテキストの可用性 を参照してください。

4. LaunchDarkly プロジェクトの規約を確認します。 オプションで list-flags を使用して既存のフラグを確認します:

   • どのようなタグが一般的に使用されていますか?
   • フラグは一時または永続としてマークされていますか?
   • プロジェクトにはどのような命名パターンが存在しますか?

ステップ 2: 適切なフラグタイプを決定する

ユーザーのニーズに基づいて、適切なフラグ設定を選択します。完全なガイドについては フラグのタイプとパターン を参照してください。

クイック判断:

ユーザーの意図	フラグの種類	バリエーション
「機能をオン/オフに切り替える」	boolean	true / false
「機能を段階的にロールアウトする」	boolean	true / false
「オプション間で A/B テストを行う」	multivariate (string)	ユーザー定義の値
「数値のしきい値を設定する」	multivariate (number)	ユーザー定義の値
「異なる設定オブジェクトを配信する」	multivariate (JSON)	ユーザー定義の値

適用すべきデフォルト:

• ユーザーがこれが永続的/長期間存続するフラグであると明示的に述べない限り、temporary: true を設定します。ほとんどのフラグはリリースフラグであり、最終的にはクリーンアップされるべきです。
• 名前が提供されていない場合は、名前から key を生成します (例: 「New Checkout Flow」→ new-checkout-flow)。ただし、命名規則が存在する場合はコードベースの命名規則に一致させます。
• ユーザーが言及した機能領域、チーム、またはコンテキストに基づいて、関連するタグを提案します。

ステップ 3: LaunchDarkly でフラグを作成する

ステップ 2 で決定した設定を使用して、create-flag を使います。

作成後:

• フラグはすべての環境で ターゲティング OFF の状態で作成されます。
• ターゲティングがオンになるまで、フラグは全員に offVariation を配信します。
• フラグをオンに切り替え、必要に応じてロールアウトルールを設定するには、フラグターゲティングスキル を使う必要があることをユーザーに伝えてください。

ステップ 4: コードにフラグ評価を追加する

次に、ステップ 1 で見つけたパターンに合わせて、フラグを評価するコードを追加します。

1. コードベースがすでに使用しているのと同じ SDK パターンを使用します。 ラッパーがある場合はラッパーを使用します。定数がある場合は、新しいキーを定数ファイルに追加します。
2. 適切なデフォルト値を使用します。 コード内のデフォルト (フォールバック) 値は「安全な」動作、通常はフラグ導入前の既存の動作にします。これにより、SDK が LaunchDarkly に到達できない場合でも機能がオフのままであることが保証されます。
3. 条件分岐ロジックを追加します。 新しい動作をフラグチェックでラップします。
4. 両方の分岐を処理します。 各バリエーションのコードパスが明確で完全であることを確認します。

言語およびフレームワーク別の実装例については、SDK 評価パターン を参照してください。

ステップ 5: 確認する

フラグが正しく設定されていることを確認します:

1. コードがコンパイル/リントを通過する。 プロジェクトのビルドまたはリントのステップを実行します。
2. フラグが LaunchDarkly に存在する。 get-flag を使って、正しい設定で作成されたことを確認します。
3. 両方のコードパスが動作する。 フラグオフのパスは既存の動作を維持し、フラグオンのパスは新機能を有効にします。
4. デフォルト値が安全である。 LaunchDarkly に到達できない場合、コードはデフォルトにフォールバックします。それが既存の/安全な動作であることを確認してください。

フラグ設定の更新

ユーザーがフラグのメタデータ (ターゲティングではなく) を変更したい場合は、update-flag-settings を使用します。サポートされている変更:

変更	指示
名前の変更	{kind: "updateName", value: "New Name"}
説明の更新	{kind: "updateDescription", value: "New description"}
タグの追加	{kind: "addTags", values: ["tag1", "tag2"]}
タグの削除	{kind: "removeTags", values: ["old-tag"]}
一時的としてマーク	{kind: "markTemporary"}
永続的としてマーク	{kind: "markPermanent"}

複数の指示を 1 回の呼び出しでバッチ処理できます。これらの変更はプロジェクト全体に適用され、環境固有ではありません。

重要: メタデータの更新 (上記) は、ターゲティングの変更 (トグル、ロールアウト、ルール) とは別です。ユーザーが誰に何を表示するかを変更したい場合は、フラグターゲティングスキル に誘導してください。

重要なコンテキスト

• フラグキーは不変です。 一度作成すると、フラグのキーは変更できません。慎重に選択してください。
• フラグは OFF で開始します。 作成によってフラグが有効になることはありません。これは安全機能です。
• コード内のデフォルト値はあなたのセーフティネットです。 これは SDK が LaunchDarkly に接続できない場合に配信されるものです。常に「安全な」/既存の動作をデフォルトとして使用してください。
• 既存のコードベースの規約に従ってください。 最もよくある間違いは、チームがすでに行っていることと一致しないフラグパターンを導入することです。ステップ 1 はこれを防ぐために存在します。

参照

• フラグの種類とパターン: ブール値と多変量、命名規則、設定のベストプラクティス
• SDK 評価パターン: 各 SDK でフラグを評価する方法 (一般的なラッパーパターンを含む)
• コンテキストの可用性: ターゲティングが使用できるコンテキストの種類/属性と、フラグが読み取られるサーフェスとの対応 (フラグが単純なオン/オフスイッチではなくターゲティングを行うようになった時点で関係します)