Qu’est-ce qu’une checklist de release ?
Une checklist de release transforme la mise en production en étapes à cocher sur le ticket : préparation, build et artefacts, approbation du changement, déploiement, tests de contrôle, surveillance, rollback et clôture. Les rubriques restent stables ; les cases cochées, les SHA et les notes évoluent à chaque déploiement.
Chaque équipe livre à sa manière. Celles qui pratiquent la livraison continue retireront les lignes liées à la fenêtre de changement ; les trains de release hebdomadaires les conserveront. Utilisez cette liste comme point de départ, puis enregistrez votre version pour que la mise en production du vendredi ne dépende pas de la mémoire de chacun.
Pourquoi garder la checklist de release sur le ticket
Un runbook stocké dans un wiki ou un fil Slack se manque facilement au démarrage du déploiement. Une checklist sur le ticket conserve le SHA, la fenêtre, les tests de contrôle et le plan de rollback là où le changement est déjà suivi. Responsables de release, équipes d’astreinte et développeurs voient tous ce qu’il reste à faire.
Le même cadre convient à la livraison continue comme à une fenêtre de changement : vous ouvrez le ticket, identifiez les étapes restantes, les cochez au fil de l’eau et consignez tout écart. Conservez l’approbation, la communication et le rollback pour les releases à risque ; retirez-les pour une simple activation de feature flag.
Quand l’utiliser
Utilisez une checklist de release dès qu’un changement part en production : sur la story livrée ou sur un ticket de changement dédié lorsque le déploiement possède son propre responsable, ses dates et son workflow. Appliquez-la automatiquement au passage à Ready to release ou Deploying pour faire apparaître le runbook avant la fenêtre. Allégez-la pour les déploiements continus à faible risque ; conservez approbation, communication et rollback si le changement est visible des utilisateurs ou difficile à annuler.
Release, tests QA et Definition of Done
La checklist de tests QA correspond au parcours de test effectué avant l’ouverture de la fenêtre. La Definition of Done constitue le seuil de sortie commun à la story : revue, tests et préparation à la mise en production. La checklist de release est le runbook de lancement du changement réellement livré. Gardez ces listes séparées pour distinguer le parcours de test, le seuil de livraison et la fenêtre de production. Les critères d’acceptation continuent de décrire le comportement mis en ligne.
Release et déploiement : un exemple pour démarrer
Pour créer votre première checklist de release, partez de l’exemple ci-dessous. Copiez la liste, puis collez-la dans le champ Checklist for Jira d’un ticket de changement ou de release. Enregistrez-la idéalement comme modèle et appliquez-la automatiquement au passage à Ready to release : chaque déploiement retrouve le même cadre et les mêmes rubriques. Supprimez les lignes inutiles et ajoutez celles qu’exige votre processus.
Release et déploiement
- Préparation de la release
- Le changement, les feature flags et les clés des tickets sont indiqués sur ce ticket
- Les parties prenantes et l’équipe d’astreinte connaissent la fenêtre, ou la raison du déploiement continu
- Le risque, le périmètre d’impact et les points à surveiller sont consignés sur le ticket
- Build et artefacts
- L’artefact de build ou le SHA du commit est enregistré
- La vérification en préproduction ou en staging est terminée, ou sa dérogation est consignée
- Les secrets, certificats et accès nécessaires au déploiement sont en place
- Sécurité et approbation du changement
- La revue de sécurité ou les éléments d’analyse des menaces sont liés si le changement est sensible
- Les approbations exigées par votre politique sont enregistrées sur le ticket
- Déploiement
- Les étapes de déploiement en production ont été exécutées dans l’ordre documenté
- Les migrations ou changements de configuration sont terminés sans erreur non résolue
- Les feature flags ciblent bien l’audience prévue
- Tests de contrôle et surveillance
- Les tests de contrôle du parcours de production sont réussis
- Le taux d’erreur, la latence et les indicateurs métier restent normaux pendant la fenêtre
- Les tableaux de bord et alertes du service modifié sont ouverts
- Rollback, communication et clôture
- Le plan de rollback ou de désactivation est suffisamment testé pour être utilisé
- Le support, la relation client ou la page de statut sont mis à jour si les utilisateurs voient le changement
- Un incident ou un ticket de suivi est lié si la release a provoqué un impact négatif
- Les notes post-release et les tâches restantes sont consignées sur ce ticket
Ce cadre doit rester sur le changement livré. Dans Checklist for Jira, vous ajoutez ou cochez les éléments dans le panneau du ticket, enregistrez les rubriques comme modèle de projet ou modèle global, puis l’appliquez automatiquement au passage à Ready to release. Vous pouvez aussi l’ajouter manuellement via Add → Add from template dès que nécessaire.
Mettez la checklist sur l’élément de travail, pas dans la description
Checklist for Jira apporte les modèles, l’automatisation, les validateurs de workflow et un agent Rovo. Gratuit pour les équipes jusqu’à 10 utilisateurs.
Enregistrez un modèle, automatisez le runbook
- Checklist for Jira ajoute un panneau de checklist à la vue du ticket. Collez l’exemple ci-dessus dans un ticket de changement ou de release, adaptez les lignes à votre processus, puis enregistrez la structure comme modèle de projet ou modèle global dans Checklist settings.
- Marquez le modèle comme Protected si vous souhaitez verrouiller le runbook pendant que l’équipe coche les éléments, afin que les étapes ne disparaissent pas discrètement d’un déploiement à l’autre.
- Utilisez l’automatisation propre au modèle pour joindre la checklist de release au passage à Ready to release ou Deploying. Ces automatisations sont intégrées à Checklist for Jira et ne consomment aucun crédit Jira Automation.
- Si votre équipe souhaite un contrôle strict, ajoutez un validateur de complétion au statut de livraison et limitez-le à ce modèle. Une post-fonction peut réinitialiser la liste après un rollback avant une nouvelle tentative. Jira Automation peut appliquer, terminer ou réinitialiser cette même liste lorsque la condition dépasse un simple statut.
- Associez-la à la checklist de tests QA avant la fenêtre et à la Definition of Done sur la story. Consultez également le guide d’automatisation.
Associez-la aux autres checklists de livraison
Gardez la checklist de tests QA sur le ticket jusqu’à la validation du parcours. Ajoutez la Definition of Done à la story pour que le seuil de livraison soit visible dès le premier jour. Utilisez la Definition of Ready pendant l’affinage si votre équipe souhaite mieux cadrer les demandes. Parcourez le catalogue de modèles pour découvrir l’ensemble des modèles.
Questions fréquentes
La release doit-elle être suivie dans un ticket Jira distinct ?
Si le déploiement constitue un véritable projet avec son propre responsable, ses dates et son workflow, créez un ticket ou une sous-tâche dédiée. Si le runbook se résume à des contrôles sur un changement déjà suivi, gardez la checklist sur ce ticket.
Toutes les équipes ont-elles besoin de la même checklist de release ?
Non. Commencez avec un modèle, puis adaptez-le. Les équipes en livraison continue retirent souvent les étapes liées à la fenêtre de changement et aux approbations. Un train de release hebdomadaire et réglementé conservera approbations, communication et rollback. Créez un second modèle si deux produits utilisent durablement des runbooks différents.
Les modèles globaux peuvent-ils servir à tous les projets ?
Oui. Les administrateurs Jira enregistrent les modèles globaux, tandis que les administrateurs de projet gèrent les modèles de projet. Un runbook global marqué Protected constitue une base solide lorsque plusieurs équipes doivent livrer de la même manière.
Comment réinitialiser la liste après un rollback ?
Ajoutez une post-fonction ou une action Reset all de Jira Automation à la transition qui quitte le statut de livraison, en la ciblant pour que seule la checklist de release soit réinitialisée. Le guide d’automatisation détaille la réinitialisation et les validateurs de complétion.
Mettez la checklist sur l’élément de travail, pas dans la description
Checklist for Jira apporte les modèles, l’automatisation, les validateurs de workflow et un agent Rovo. Gratuit pour les équipes jusqu’à 10 utilisateurs.