Ciblage et déploiement des drapeaux LaunchDarkly

Vous utilisez une skill qui vous guidera à travers la modification de qui voit quoi pour un drapeau de fonctionnalité. Votre tâche est de comprendre l'état actuel du drapeau, de déterminer la bonne approche de ciblage pour ce que l'utilisateur souhaite, d'apporter les modifications de manière sûre et de vérifier l'état résultant.

Prérequis

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

Outils MCP requis :

• get-flag : comprendre l'état actuel avant d'apporter des modifications
• toggle-flag : activer ou désactiver le ciblage d'un drapeau dans un environnement
• update-rollout : modifier la variation de la règle par défaut (fallthrough) ou le déploiement en pourcentage
• update-targeting-rules : ajouter, supprimer ou modifier des règles de ciblage personnalisées
• update-individual-targets : ajouter ou supprimer des utilisateurs/contextes spécifiques du ciblage individuel

Outils MCP optionnels :

• copy-flag-config : copier la configuration de ciblage d'un environnement à un autre
• create-approval-request : créer une demande d'approbation quand les modifications directes sont bloquées
• list-approval-requests : vérifier les demandes d'approbation en attente pour un drapeau
• apply-approval-request : appliquer une demande d'approbation déjà approuvée

Concept fondamental : Ordre d'évaluation

Avant d'apporter des modifications de ciblage, comprenez comment LaunchDarkly évalue les drapeaux. Cela détermine ce que vos modifications font réellement :

1. Le drapeau est OFF -> Servir l'offVariation à tous. Rien d'autre n'importe.
2. Cibles individuelles -> Si le contexte correspond à une liste de cibles spécifiques, servir cette variation. Priorité la plus élevée.
3. Règles personnalisées -> Évaluer les règles de haut en bas. La première règle correspondante gagne.
4. Règle par défaut (fallthrough) -> Si rien d'autre n'a correspondu, servir cette variation ou ce déploiement.

Cela signifie : si vous ajoutez une règle de ciblage mais que le drapeau est OFF, personne ne voit la modification. Si vous définissez un déploiement en pourcentage sur la règle par défaut mais qu'il existe une cible individuelle, cet utilisateur ciblé contourne le déploiement.

Flux de travail

Étape 1 : Comprendre l'état actuel

Avant de changer quoi que ce soit, vérifiez ce qui est déjà configuré.

1. Confirmez l'environnement. « L'activer » sans préciser d'environnement est ambigu. Confirmez toujours quel environnement l'utilisateur souhaite. Préférez demander plutôt que supposer.
2. Récupérez le drapeau. Utilisez get-flag avec l'environnement cible pour voir :
   • on : Le ciblage est-il actuellement activé ?
   • fallthrough : Quelle est la règle par défaut ? (variation ou déploiement en pourcentage)
   • offVariation : Qu'est-ce qui est servi quand le drapeau est off ?
   • rules : Y a-t-il des règles de ciblage personnalisées ?
   • targets : Y a-t-il des utilisateurs/contextes ciblés individuellement ?
   • prerequisites : Y a-t-il des drapeaux dont celui-ci dépend ?
3. Évaluez la complexité. Un drapeau sans règles et sans cibles individuelles est simple. Un drapeau avec plusieurs règles, cibles et prérequis nécessite plus de prudence.

Étape 2 : Déterminer la bonne approche

En fonction de ce que l'utilisateur souhaite et de ce que vous avez trouvé, choisissez le bon outil et la bonne stratégie. Consultez Targeting Patterns pour la référence complète.

Scénarios courants :

Étape 3 : Exécuter la liste de contrôle de sécurité

Avant d'appliquer des modifications, en particulier en production, parcourez la liste de contrôle de sécurité. Les vérifications clés :

1. Bon environnement ? Vérifiez à nouveau que vous ciblez l'environnement prévu.
2. Approbation requise ? Certains environnements nécessitent des flux de travail d'approbation. Si un outil de mutation retourne requiresApproval: true :
   • Informez l'utilisateur que cet environnement nécessite des approbations.
   • Partagez l'approvalUrl si fourni.
   • Proposez de créer une demande d'approbation avec create-approval-request en utilisant les mêmes instructions (retournées dans le champ instructions de la réponse).
   • NE tentez PAS de contourner l'approbation ou d'auto-approuver.
   • Consultez Approval Workflows pour le processus complet.
3. Drapeaux prérequis ? Si ce drapeau a des prérequis, ils doivent être satisfaits avant que le ciblage ne fonctionne comme prévu.
4. Impact de l'ordre des règles ? Si vous ajoutez des règles, considérez où elles se situent dans l'ordre d'évaluation. Les règles s'évaluent de haut en bas, la première correspondance gagne.
5. Incluez un commentaire. Ajoutez toujours un commentaire de piste d'audit, en particulier pour les modifications en production.

Étape 4 : Appliquer les modifications

Utilisez l'outil approprié pour la modification. Points clés :

• toggle-flag : Spécifiez on: true ou on: false, l'env et un comment.
• update-rollout : Utilisez rolloutType: "percentage" avec des poids conviviaux (par exemple, 80 pour 80 %) qui totalisent 100, ou rolloutType: "variation" avec un variationIndex.
• update-targeting-rules : Les instructions supportent addRule, removeRule, updateRuleVariationOrRollout, addClauses, removeClauses, reorderRules.
• update-individual-targets : Les instructions supportent addTargets, removeTargets, addContextTargets, removeContextTargets, replaceTargets.

Consultez Targeting Patterns pour des exemples d'instructions détaillées.

Étape 5 : Vérifier

Après avoir appliqué les modifications, confirmez le résultat :

1. Récupérez le drapeau mis à jour. Utilisez get-flag à nouveau pour vérifier le nouvel état.
2. Confirmez ce que l'utilisateur attend. Décrivez le ciblage résultant en langage clair :
   • « Le drapeau est maintenant ON en production, servant true à 25 % des utilisateurs et false à 75 %. »
   • « Les utilisateurs beta voient maintenant la variation A. Tous les autres reçoivent la valeur par défaut (variation B). »
3. Vérifiez les effets secondaires. S'il y a des règles ou des cibles individuelles, assurez-vous que la modification interagit correctement avec elles.

Gestion des environnements nécessitant une approbation

Quand un outil de mutation retourne requiresApproval: true, la modification directe a été bloquée parce que l'environnement nécessite des approbations. Suivez la référence Approval Workflows pour :

1. Créer une demande d'approbation avec create-approval-request en utilisant les instructions de la réponse bloquée
2. Informer l'utilisateur de la demande d'approbation en attente et partager les détails de la demande
3. Vérifier l'état d'approbation plus tard avec list-approval-requests si demandé
4. Appliquer la demande avec apply-approval-request une fois qu'un réviseur l'a approuvée (reviewStatus est « approved »)
5. Vérifier le résultat avec get-flag après application

Contexte important

• update-rollout utilise des pourcentages conviviaux. Passez 80 pour 80 %, pas 80000. L'outil gère la conversion de poids interne.
• Les poids doivent totaliser 100. Pour les déploiements en pourcentage, les poids sur toutes les variations doivent totaliser exactement 100.
• L'ordre des règles importe. Les règles s'évaluent de haut en bas. Réordonner les règles peut changer le comportement sans changer aucune règle individuelle.
• Les cibles individuelles sont prioritaires. Elles remplacent toutes les règles et la valeur par défaut. Ajouter quelqu'un comme cible individuelle signifie que les règles ne s'appliquent pas à lui.
• Les drapeaux « lancés » sont toujours ON. Un drapeau avec le statut « lancé » sert une variation unique à tous. Si vous voulez supprimer le drapeau, utilisez la skill de nettoyage, pas les modifications de ciblage.

Références

• Targeting Patterns : Stratégies de déploiement, construction de règles, ciblage individuel et copie entre environnements
• Safety Checklist : Vérification pré-modification, flux de travail d'approbation, sensibilisation à l'environnement
• Approval Workflows : Créer, vérifier et appliquer des demandes d'approbation