🚀 6 — Release
Release livre un changement après réussite de Prove. Déployez automatiquement en staging, puis progressivement en production.
Déployer place le code en production, désactivé. Mettre en service l’active progressivement pour les utilisateurs. Prévoyez la reprise avant le déploiement.
Objectif
| Entrée | Sortie | Responsable |
|---|---|---|
| Un changement ayant franchi 5 — Prove | De la valeur en production, observable et réversible | DevOps |
Modèle
- Trunk-based : un tag sur
maindéclenche la release. - Chaque release produit un artefact immuable et versionné.
- Le déploiement est automatique vers
staging, puis progressif versproduction. - Le feature flag
enablepermet de déployer le code avant de l’activer pour les utilisateurs. - Chaque release utilise la métrique de résultat déjà engagée dans le ticket de backlog de 1 — Triage. L’étape 7 — Learn prend ensuite le relais et l’évalue une fois le déploiement progressif terminé.
Le feature flag enable constitue la véritable décision de mise en service. Tout ce qui précède relève du déploiement. Les chemins de retour arrière sont détaillés dans la section Rollback ci-dessous.
Règles de déploiement progressif (rollout)
Les outils de déploiement appliquent des règles fixes à chaque étape. L’IA ne décide pas de la promotion ni du rollback.
| Règle | Ce qu’elle vérifie | Effet |
|---|---|---|
| Promotion | Les métriques de santé et les métriques métier restent dans leurs seuils pendant toute la fenêtre d’observation | Le déploiement passe automatiquement à l’étape suivante |
| Vérification de santé (Health check) | Smoke tests et tests QA en staging, puis taux d’erreur, latence et saturation à chaque palier en production | Une vérification en échec interrompt le déploiement |
| Seuil de rollback | Une limite déclarée par changement avant le déploiement | Son franchissement déclenche automatiquement le rollback |
La surveillance des problèmes après la mise en service complète relève de 7 — Learn.
Rollback
| Mécanisme | Délai d’effet | Utilisé pour |
|---|---|---|
| Désactivation du feature flag | Quelques secondes | Régressions fonctionnelles ou comportementales |
| Bascule du trafic vers la version précédente | < 1 minute | Défaillances liées au déploiement |
| Redéploiement de l’artefact précédent | Quelques minutes | Problèmes de configuration ou d’exécution |
| Correctif en avant (Forward fix) | Quelques heures | Problèmes affectant les données où un retour arrière est risqué |
Tout changement ayant un rayon d’impact Élevé ou Critique voit son mécanisme de rollback désigné dans le dossier Think et validé lors de 5 — Prove avant d’être déployé. Un changement sans chemin de rollback n’est jamais déployé.
Où l’IA est utilisée
L’IA prépare versions, dossiers, notes de version et changelogs. Les contrôles autorisent la publication ; les outils décident de promouvoir, suspendre ou annuler. Les personnes traitent les échecs non résolus, sans signature systématique.
Agents et skills
L’étape Release sépare la déclaration de l’exécution, en s’appuyant sur des primitives publiées par coding-pal :
Primitives de déclaration et de planification
- Un agent Release Planner synthétise le rayon d’impact et le rollback issus de
think.md, le périmètre de fichiers deplan.mdet la métrique de résultat detriage.mdau sein de la déclarationrelease.md. - Une instruction release impose les standards : déployer n’est pas mettre en service, les feature flags contrôlent l’exposition, les livraisons restent bornées, les artefacts sont immuables et l’autorisation automatisée est consignée avant le tag.
Compétences de jalon déterministe et de déploiement
- Un validateur release-plan (
validate-release.mjs) vérifie le risque, les pourcentages de déploiement, les seuils de santé et le rollback. - Un évaluateur release-plan (
evaluate-rollout.mjs) utilise les métriques en direct pour renvoyer promote, hold ou rollback.
Infrastructure de pipeline et dossiers
- Le dossier Release (
specs/issue-<n>/release.md) définit les étapes de déploiement progressif, les fenêtres d’observation, les seuils et la métrique de résultat pour Learn. - Un modèle de workflow de release fournit le squelette CI/CD de déploiement progressif (tag d’artefact, smoke check en staging, paliers canary et exécution automatisée du rollback), adapté à la plateforme de l’équipe.
Consultez le guide Release de coding-pal.
Pipelines de publication et de déploiement
Publication et déploiement utilisent la révision et les preuves de Prove, sur toute plateforme CI/CD. Appliquez les règles de statut communes. Publier un package ou la documentation ne signifie pas que le déploiement en production est terminé.
Publier un package ou un artefact
Un pipeline de publication distribue un package, une image de conteneur ou un autre artefact de livraison préparé et versionné :
- Vérifie la révision, la version, le tag et les preuves.
- Construit et teste l’artefact, ou vérifie un build immuable existant.
- Vérifie la documentation, les métadonnées, le contenu et la provenance.
- Choisit le registre et le canal ; effectue une simulation si possible.
- Publie sauf en mode vérification seule, confirme la disponibilité et notifie les consommateurs.
Point d’arrêt : simulation, publication confirmée, pause demandée ou échec. Ce pipeline n’implémente ni ne fusionne de changement.
Une validation réussie ne signifie pas publié. Consignez la version et le résultat du registre avant Done si la publication est requise. Puis reprenez le travail dépendant.
Déployer la documentation
Un pipeline documentaire construit et déploie le site associé à la révision livrée :
- Restaure la révision livrée et construit le code nécessaire à la documentation.
- Installe les dépendances du site, construit et valide la documentation.
- Stocke le site généré sous forme d’artefact de déploiement versionné.
- Déploie automatiquement vers l’hébergement configuré après réussite des contrôles d’environnement, puis vérifie la disponibilité.
Point d’arrêt : un déploiement documentaire vérifié, une pause explicitement demandée ou un échec de build/déploiement. Ce pipeline est distinct de la validation des changements et de la publication ; la politique de livraison détermine son déclencheur et si son résultat est requis pour terminer le travail.
Jalon de sortie
Une release est terminée lorsque le déploiement a atteint 100 %, que la fenêtre d’observation s’est écoulée sans franchissement de seuil et que le tableau de bord d’observabilité du changement est actif dans Learn.