Créer et configurer un flag LaunchDarkly

Vous utilisez une skill qui vous guidera à travers l'introduction d'un nouveau feature flag dans une codebase. Votre travail consiste à explorer comment les flags sont déjà utilisés dans cette codebase, créer le flag dans LaunchDarkly de façon cohérente, ajouter le code d'évaluation en respectant les patterns existants, et vérifier que tout est correctement intégré.

Prérequis

Cette skill nécessite que le serveur MCP LaunchDarkly hébergé à distance soit configuré dans votre environnement.

Outils MCP requis :

• create-flag : créer un nouveau feature flag dans un projet
• get-flag : vérifier que le flag a été créé correctement

Outils MCP optionnels (améliorent le workflow) :

• list-flags : parcourir les flags existants pour comprendre les conventions de nommage et les tags
• update-flag-settings : mettre à jour les métadonnées du flag (nom, description, tags, statut temporaire/permanent)

Workflow

Étape 1 : Explorer la codebase

Avant de créer quoi que ce soit, comprenez comment cette codebase utilise les feature flags.

1. Trouvez le SDK. Cherchez les imports ou l'initialisation du SDK LaunchDarkly :

   • Cherchez launchdarkly, ldclient, ld-client, LDClient dans les imports
   • Vérifiez package.json, requirements.txt, go.mod, Gemfile, ou équivalent pour la dépendance du SDK
   • Identifiez quel SDK est utilisé (server-side Node, React, Python, Go, Java, etc.)

2. Trouvez les évaluations de flags existantes. Cherchez les appels de variation pour comprendre les patterns que cette codebase utilise :

   • Appels SDK directs : variation(), boolVariation(), useFlags(), etc.
   • Patterns wrapper : Cette codebase abstrait-elle les flags derrière un service ou un utilitaire ?
   • Définitions de constantes : Les clés de flags sont-elles définies comme constantes quelque part ?
   • Voir SDK Evaluation Patterns pour les patterns par langage

3. Comprendre les conventions. Regardez les flags existants pour apprendre :

   • Convention de nommage : Les clés sont-elles en kebab-case, snake_case, camelCase ?
   • Organisation : Les clés de flags sont-elles co-localisées avec les features, ou centralisées dans un fichier de constantes ?
   • Valeurs par défaut : Quelles valeurs par défaut les évaluations existantes utilisent-elles ?
   • Construction du context/utilisateur : Comment cette codebase construit-elle l'objet utilisateur/context passé au SDK ?

4. Vérifiez les conventions du projet LaunchDarkly. Optionnellement, utilisez list-flags pour voir les flags existants :

   • Quels tags sont couramment utilisés ?
   • Les flags sont-ils marqués comme temporaires ou permanents ?
   • Quels patterns de nommage existent dans le projet ?

Étape 2 : Déterminer le bon type de flag

En fonction de ce dont l'utilisateur a besoin, choisissez la configuration de flag appropriée. Voir Flag Types and Patterns pour le guide complet.

Décision rapide :

Valeurs par défaut à appliquer :

• Définissez temporary: true sauf si l'utilisateur dit explicitement que c'est un flag permanent/long-term. La plupart des flags sont des release flags qui devraient être nettoyés à terme.
• Générez une key à partir du nom si non fournie (ex. « New Checkout Flow » -> new-checkout-flow), mais respectez la convention de nommage de la codebase s'il en existe une.
• Suggérez des tags pertinents en fonction du domaine de la feature, de l'équipe, ou du contexte mentionné par l'utilisateur.

Étape 3 : Créer le flag dans LaunchDarkly

Utilisez create-flag avec la configuration déterminée à l'étape 2.

Après la création :

• Le flag est créé avec le ciblage désactivé dans tous les environnements.
• Le flag sert la offVariation à tout le monde jusqu'à ce que le ciblage soit activé.
• Rappelez à l'utilisateur qu'il devra utiliser la skill de ciblage de flag pour l'activer et optionnellement mettre en place des règles de déploiement.

Étape 4 : Ajouter l'évaluation du flag au code

Maintenant, ajoutez le code pour évaluer le flag, en respectant les patterns que vous avez trouvés à l'étape 1.

1. Utilisez les mêmes patterns SDK que ceux que la codebase utilise déjà. S'il y a un wrapper, utilisez-le. S'il y a des constantes, ajoutez la nouvelle clé au fichier de constantes.
2. Utilisez une valeur par défaut appropriée. La valeur par défaut (fallback) dans le code devrait être le comportement « safe » : généralement le comportement existant avant le flag. Cela garantit que la feature reste désactivée si le SDK ne peut pas atteindre LaunchDarkly.
3. Ajoutez la logique conditionnelle. Enrobez le nouveau comportement d'une vérification de flag.
4. Gérez les deux branches. Assurez-vous que le chemin de code pour chaque variation est clair et complet.

Voir SDK Evaluation Patterns pour les exemples d'implémentation par langage et framework.

Étape 5 : Vérifier

Confirmez que le flag est correctement configuré :

1. Le code compile/passe le linting. Lancez l'étape de build ou de lint du projet.
2. Le flag existe dans LaunchDarkly. Utilisez get-flag pour confirmer qu'il a été créé avec la bonne configuration.
3. Les deux chemins de code fonctionnent. Le chemin flag-off préserve le comportement existant ; le chemin flag-on active la nouvelle feature.
4. La valeur par défaut est safe. Si LaunchDarkly est injoignable, le code revient à la valeur par défaut : assurez-vous que c'est le comportement existant/safe.

Mettre à jour les paramètres du flag

Si l'utilisateur veut changer les métadonnées du flag (pas le ciblage), utilisez update-flag-settings. Modifications supportées :

Plusieurs instructions peuvent être groupées dans un seul appel. Ces modifications sont au niveau du projet, non spécifiques à un environnement.

Important : Les mises à jour de métadonnées (ci-dessus) sont séparées des modifications de ciblage (toggle, déploiement, règles). Si l'utilisateur veut changer qui voit quoi, dirigez-le vers la skill de ciblage de flag.

Contexte important

• Les clés de flags sont immuables. Une fois créée, la clé d'un flag ne peut pas être modifiée. Choisissez soigneusement.
• Les flags commencent DÉSACTIVÉS. La création ne signifie jamais l'activation d'un flag. C'est une mesure de sécurité.
• La valeur par défaut dans le code est votre filet de sécurité. C'est ce qui est servi quand le SDK ne peut pas se connecter à LaunchDarkly. Utilisez toujours le comportement « safe » / existant comme défaut.
• Suivez les conventions de la codebase existante. L'erreur la plus courante est d'introduire un pattern de flag qui ne correspond pas à ce que l'équipe fait déjà. L'étape 1 existe pour prévenir cela.

Références

• Flag Types and Patterns : Boolean vs multivariate, conventions de nommage, meilleures pratiques de configuration
• SDK Evaluation Patterns : Comment évaluer les flags dans chaque SDK, incluant les patterns wrapper courants