Préparer la fenêtre
Cette vérification rend la décision traçable et réutilisable lors d’une prochaine mise en production.
La fenêtre est close après validation technique et métier. Conservez version, approbations, alertes, mesures et décision de retour dans le ticket pour la revue suivante.
Le ticket doit préciser le motif, la version et la personne qui valide. Après action, vérifiez métriques, support, jobs et ressources temporaires avant de fermer la fenêtre.
La validation finale doit inclure le support, les métriques et les tâches planifiées. Gardez la version précédente et les commandes de retour accessibles. Un changement terminé est celui dont le fonctionnement et les effets secondaires ont été contrôlés.
Noter la décision
Conservez version, responsable, validations, mesures et décision de retour. Une revue le lendemain confirme les jobs, exports, webhooks et demandes support. Les ressources temporaires sont supprimées après contrôle.
Confirmer la couverture
Une personne doit décider d’un retour et une autre pouvoir suivre le plan. Vérifiez accès, alertes, fournisseur et restauration avant l’heure prévue. Un changement sans couverture documentée doit être reporté.
Répéter avant production
Faites une répétition sur la préproduction avec les mêmes images, variables et étapes. Mesurez construction, validation, bascule et retour. Une personne extérieure à la rédaction doit suivre le plan afin de repérer les commandes ambiguës.
Traiter les données
Une migration peut exiger une période de compatibilité entre anciennes et nouvelles versions. Définissez écritures autorisées, jobs exclusifs et reprise après interruption. Testez la restauration avant la fenêtre et confirmez qui décide d’un retour.
Fermer proprement
Après publication, comparez erreurs, latence, files et parcours métier. Le support doit connaître la version et le canal d’escalade. Conservez commit, image, approbations et mesures, puis supprimez accès temporaires et ressources de test.
Répéter l’opération
Faites une répétition sur la préproduction avec les mêmes images, variables et étapes. Mesurez construction, validation, bascule et retour. Une personne extérieure à la rédaction doit suivre le plan afin de repérer les commandes ambiguës.
Traiter les données
Une migration peut exiger une période de compatibilité entre anciennes et nouvelles versions. Définissez les écritures autorisées, les jobs exclusifs et la manière de reprendre un message après interruption. Testez la restauration avant la fenêtre.
Revoir le résultat
Après chaque déploiement, notez erreurs, latence, support et décisions. Supprimez les accès temporaires et les ressources de test. Une anomalie doit rester ouverte jusqu’à une correction vérifiée.
Un déploiement hors heures doit préciser début, fin, personnes présentes et critères d’arrêt. Vérifiez certificats, quotas, identités de pipeline, accès au registre, jobs et dépendances externes avant l’ouverture de la fenêtre.
Les migrations qui touchent des données demandent une vérification séparée. Définissez si les écritures sont suspendues, comment les utilisateurs sont informés et quelle sauvegarde permet un retour. Une opération nocturne ne justifie pas de supprimer une validation.
Après publication, comparez erreurs, latence, files et parcours métier. Le support doit connaître la version active et le canal d’escalade. Conservez commit, image, approbations, mesures et décision finale pour la revue suivante.
Si la couverture disparaît, bloquez ou reportez un changement à risque. Un pipeline peut vérifier la présence d’une validation et ouvrir un incident lorsqu’un contrôle échoue.
Un déploiement réalisé en dehors des heures habituelles réduit parfois l’impact utilisateur, mais il peut aussi laisser moins de personnes disponibles pour diagnostiquer un problème. Une règle doit combiner risque, couverture et capacité de retour.
Choisir une fenêtre
Regardez trafic, traitements planifiés, support et dépendances externes. Évitez de superposer une migration de données et un changement de réseau sans raison. La fenêtre doit prévoir validation et retour, pas seulement la commande de publication.
Vérifier la présence
Indiquez les personnes joignables, le canal incident et la personne qui décide. Si personne ne peut confirmer le résultat, reportez un changement à risque. Un pipeline peut bloquer automatiquement la production quand la couverture prévue manque.
Observer après livraison
Comparez métriques, erreurs, files et parcours utilisateur. Conservez la version précédente. Le plan de bascule décrit les validations à réaliser après trafic.
Sources : Google SRE release engineering, AWS deployment risks.
Préparer les utilisateurs
Le support doit connaître la version active, les effets visibles et la procédure d’escalade. Prévenez les équipes métier lorsqu’une fonction sera indisponible. Après la livraison, confirmez le résultat avec un parcours représentatif, puis surveillez les erreurs et les demandes entrantes.
Un déploiement nocturne ne doit pas cacher une anomalie jusqu’au matin. Programmez une alerte sur les indicateurs qui ont un propriétaire et demandez une validation automatique lorsque c’est possible. Si une vérification échoue, le pipeline doit conserver la version et ouvrir un incident.
Conserver la preuve
Archivez commit, image, plan, approbations et mesures post-déploiement. Ces éléments expliquent la décision et rendent un audit possible. Ils aident aussi une personne qui reprend la permanence après la fenêtre à comprendre ce qui a changé.