Enregistrer une Version Automatisée d'un Flag

Tu utilises une skill qui prend un flag de fonctionnalité existant (créé EN ATTENTE) qui protège le changement d'une pull request, et enregistre un déploiement automatisé afin que le changement se déploie sans risque dès la fusion de la PR — sans basculement manuel du flag. Il laisse à l'équipe le soin de respecter ses politiques de déploiement par environnement et honore toute intention de déploiement exprimée par l'utilisateur.

C'est l'étape de déploiement du workflow flag-PR, et elle est volontairement atomique :

Au moment où cette skill s'exécute, le flag existe (EN ATTENTE) et le code de protection est câblé et poussé. Cette skill n'enregistre que le déploiement — elle ne crée jamais de flags ni ne modifie du code. Elle peut être pilotée directement par une automation, ou comme dernière étape de l'orchestrateur flag-and-release-change.

Le déploiement n'est pas la version. La fusion livre le chemin de contrôle (flag EN ATTENTE) ; la version est l'opération flag que ce déploiement effectue après, régie par la politique de l'environnement.

Honorer un gel est la seule chose qu'il faut faire correctement. Il n'existe pas de type de version « gel », et policy n'est PAS une porte manuelle. À la fusion, policy effectue automatiquement la version de l'environnement (immédiate, progressive ou gardée) sans étape de promotion humaine — un déploiement gardé démarre tout seul l'instant où la PR fusionne. Donc enregistrer un environnement gelé comme policy ne le gèle pas ; il se déploie à la fusion, avant toute date notBefore. La seule façon de geler un environnement est de l'omettre entièrement du tableau environments, ce qui laisse le flag EN ATTENTE là-bas. Si l'utilisateur veut un environnement gelé (ou pas de déploiement avant une date), exclus-le de l'appel et rapporte-le comme gelé. En cas de doute, omets-le.

Prérequis

• Le serveur MCP LaunchDarkly hébergé à distance.
• Le flag de protection existe déjà dans LaunchDarkly, créé EN ATTENTE, avec la clé/les tags convenus.
• Une référence de pull request (repoFullName + prNumber, ou prUrl) afin que le déploiement se lie à la bonne fusion.

Outils MCP que cette skill utilise :

• create-automated-rollout-config — enregistrer le déploiement du flag en lien avec la PR (le livrable)
• match-release-policies — résoudre quelle politique de déploiement gouverne chaque environnement (appel avant de proposer le plan)
• list-release-policies — voir les politiques de déploiement du projet et les métriques qu'elles attachent automatiquement
• get-flag — confirmer que le flag existe et est EN ATTENTE avant d'enregistrer

Modèle de version complet — simple vs policy, précédence, aperçu, prérequis, adéquation des métriques : references/auto-release.md.

Phase de Planification

N'enregistre rien dans cette phase.

1. Confirme le flag. Appelle get-flag pour vérifier que le flag de protection existe et est EN ATTENTE. S'il n'existe pas encore, arrête — la création est le travail de launchdarkly-flag-create, et enregistrer un déploiement pour un flag manquant échoue de façon confuse.
2. Choisis les environnements cibles. Utilise les environnements nommés par l'utilisateur ou l'automation. Ne code pas en dur un ensemble — un changement donné ne peut pas toujours se déployer partout. Si aucun n'est nommé, énumère les vraies clés du projet et confirme l'ensemble plutôt que de supposer.
3. Aperçois la politique de chaque environnement. Appelle match-release-policies (par flagKey + environmentKey) pour résoudre, de façon déterministe, ce qu'un déploiement policy fera par environnement — winningReleaseMethod (immédiat / progressif / gardé / aucun). Ne raisonne pas sur la portée de la politique à la main. Pour un gagnant gardé, vérifie que les métriques attachées automatiquement peuvent réellement comparer ce changement (voir la note sur l'adéquation des métriques dans references/auto-release.md).
4. Capture l'intention de déploiement de l'utilisateur. Demande (brièvement, seulement si pas déjà exprimée) : déployer à la fusion, geler (enregistré mais pas encore déployé), ou attendre une date notBefore ? Une cohorte/segment à cibler en premier ? Un flag parent prérequis que celui-ci ne doit pas précéder ? L'intention est au-dessus de la politique en précédence et est honorée ou explicitement gelée — jamais silencieusement abandonnée.
5. Présente le plan par environnement et arrête. Pour chaque environnement, énonce soit le releaseType avec lequel il sera enregistré (simple / policy, et ce que cela fait à la fusion) soit qu'il sera gelé — omis de la config enregistrée pour que le flag reste EN ATTENTE là-bas — avec la raison. Attends la confirmation ; révise selon les retours.

Phase de Mise en Œuvre

Seulement après confirmation :

1. Trie chaque environnement cible dans exactement un compartiment — DÉPLOYER ou GELER. Fais-le avant de construire l'appel. Il n'y a pas de troisième compartiment, et releaseType n'en crée pas un.

   Compartiment	Sens	Ce qui va dans l'appel
   DÉPLOYER	Passe en direct à la fusion — maintenant, ou selon sa politique	Ajoute { environmentKey, releaseType } au tableau environments
   GELER	Pas encore — en attente d'une date, d'une approbation, d'un segment ou d'un flag parent	Rien. Omets-le entièrement du tableau environments ; nomme-le comme gelé dans ton rapport

   releaseType (simple vs policy) ne choisit que comment un environnement DÉPLOYER passe en direct — il ne gèle jamais un. Les deux se déploient à la fusion : simple sert true immédiatement ; policy exécute la politique de cet environnement (immédiate / progressive / gardée) automatiquement, sans étape de promotion humaine. « policy s'en remet à la politique » — pas à toi, et pas jusqu'à une date. Ne te tourne pas vers policy pour geler un environnement : cela le déploie à la fusion, avant toute notBefore. Le seul encodage d'un gel est son absence du tableau.

2. Construis environments à partir du compartiment DÉPLOYER uniquement — puis lis les clés en retour. Le tableau doit contenir chaque environnement DÉPLOYER et aucun environnement GELER. Avant d'envoyer l'appel, scanne les environmentKeys du tableau : si un environnement que tu gèles y apparaît, supprime cette entrée. L'appel n'a aucun champ pour une date ou un gel — si tu te trouves à vouloir ajouter holdUntil, notBefore, ou hold à une entrée (ou à la conserver comme policy « pour qu'elle attende »), c'est le signal que l'environnement est GELER : supprime l'entrée, n'invente pas de champ. La date et la raison vont dans ton rapport, pas dans l'appel.

   Exemple concret — « déployer staging à la fusion, geler production jusqu'au 2026-09-01 » : staging est DÉPLOYER, production est GELER.

   {
     "projectKey": "default",
     "flagKey": "new-checkout-flow",
     "environments": [{ "environmentKey": "staging", "releaseType": "simple" }],
     "repoFullName": "acme/storefront",
     "prNumber": 482
   }

   production n'apparaît nulle part dans l'appel. Tu rapportes qu'il est gelé jusqu'au 2026-09-01, avec la raison (approbation légale). Échoue fermé : si l'intention d'un environnement est ambiguë, c'est GELER, pas DÉPLOYER.

3. Enregistre le déploiement. Appelle create-automated-rollout-config avec projectKey, flagKey, le tableau environments réservé à DÉPLOYER, et la référence PR. Si un flag parent prérequis a été convenu, câble-le si la surface MCP le supporte ; sinon rapporte-le comme une étape manuelle. Détails : references/auto-release.md.

4. Vérifie. L'appel retourne created, config_id, et le plan normalisé par environnement — enregistre config_id. Rapporte seulement ce que tu as vérifié ; signale tout ce que tu n'as pas pu confirmer plutôt que de l'affirmer.

5. Rapporte le plan de déploiement par environnement + config_id ; ce qui a été gelé (et pourquoi) par rapport à ce qui se déploie à la fusion ; et ce qui se passe à la fusion (ex. « production résout politique X → déploiement gardé à la fusion ; staging sert true immédiatement ; production gelé jusqu'au 2026-08-01 selon l'intention »).

Cas Limites

Ce qu'il NE FAUT PAS Faire

• Ne crée pas le flag ou ne modifie pas le code — c'est launchdarkly-flag-create. Cette skill n'enregistre que la version.
• Ne bascule pas le flag toi-même, ou ne le bascule pas après enregistrement de la config. Le déploiement en est propriétaire ; un double basculement crée du bruit d'audit et confond le planificateur.
• Ne saute pas match-release-policies. Proposer policy sans savoir ce qu'il résout, c'est deviner.
• Ne déploie jamais silencieusement contre un gel/notBefore exprimé. Honore l'intention ou gèle — ne l'abandonne jamais.
• Ne manipule ni n'imprime les credentials. L'accès est injecté par l'environnement.

Références

• references/auto-release.md : le modèle automated-rollout / release-policy, simple vs policy, précédence (intention → override → policy → défaut), aperçu, prérequis, adéquation des métriques. (Cœur de cette skill.)
• launchdarkly-guarded-rollout : pour un déploiement sur mesure qu'aucune politique n'exprime — fixe cet env à simple ici et pilote le déploiement gardé à la main après fusion.