Objectifs
- Distinguer rollback et roll-forward.
- Choisir une dernière version stable identifiable.
- Évaluer la compatibilité de la base de données et de la configuration.
- Appliquer une checklist d’incident en neuf étapes.
Rollback et roll-forward
Un rollback restaure une version précédente connue comme stable. Un roll-forward corrige le défaut dans une nouvelle version. Le choix dépend du temps, du risque, de la capacité de restauration et de la compatibilité des données.
Le rollback se prépare avant le déploiement : version précédente disponible, procédure testée, responsabilités claires, métriques d’alerte et smoke tests prêts. Pendant l’incident, improviser augmente le temps de rétablissement.
Revenir ou corriger en avant
Le rollback est adapté si la version précédente reste compatible avec la configuration et le schéma de données. Le roll-forward peut être préférable si une migration est irréversible, si l’ancienne version ne comprend plus les données ou si un correctif minimal est plus sûr.
- Identifier précisément la version déployée et la dernière version stable.
- Conserver les artifacts antérieurs et leur configuration compatible.
- Définir des migrations de base backward-compatible lorsque possible.
- Tester régulièrement rollback et restauration, pas seulement le chemin nominal.
Exemple Kubernetes pédagogique
L’historique aide à identifier les révisions enregistrées. undo demande au Deployment de revenir à une révision antérieure. Ces commandes dépendent du contexte Kubernetes actif et ne sont jamais exécutées ici.
kubectl rollout history deployment/myappkubectl rollout undo deployment/myappUn rollback applicatif n’annule pas automatiquement une migration de base de données, une file de messages ou une modification externe. Vérifiez ces dépendances avant toute décision.
Checklist Production en neuf étapes
La sécurité des personnes et des données prime. Gardez un canal d’incident, un décideur identifié et une chronologie des actions.
- 1. Confirmer l’incident avec des signaux fiables.
- 2. Mesurer l’impact utilisateur, métier et technique.
- 3. Identifier la dernière version stable et son artifact.
- 4. Décider rollback ou roll-forward selon le risque et le délai.
- 5. Vérifier compatibilité DB, configuration, API et dépendances.
- 6. Restaurer ou déployer avec la procédure approuvée.
- 7. Lancer les smoke tests essentiels.
- 8. Surveiller erreurs, latence, trafic et métriques métier.
- 9. Documenter chronologie, cause, décision et actions de suivi.
Préparer avant le changement
Associez chaque déploiement à un plan de retour explicite. Le temps nécessaire, les commandes autorisées, les dépendances de données et les critères de succès doivent être connus avant l’ouverture de la fenêtre.
- Ne supprimez pas immédiatement le dernier artifact stable.
- Testez les migrations forward et les chemins de compatibilité.
- Protégez les credentials de restauration et journalisez leur usage.
- Faites une rétrospective après incident sans relancer aveuglément la pipeline.
Erreur fréquente : supposer que rollback signifie retour complet
Mini résumé
- Rollback restaure une version antérieure ; roll-forward livre une correction suivante.
- La version précédente doit rester compatible avec données et configuration.
- Une migration DB n’est pas automatiquement annulée avec l’application.
- La procédure, les artifacts et les validations se préparent avant le déploiement.
Mini quiz
Trois questions pour vérifier les notions essentielles de la leçon.