Rollback

Le Rollback est l'action de revenir à une version précédente connue stable d'une application après détection d'un problème suite à un déploiement. Stratégie de mitigation préférée en incident response — restaurer service rapidement avant d'investiguer root cause à tête reposée.

Méthodes : (1) Container/Image rollback — redeploy l'image précédente (Kubernetes : `kubectl rollout undo deployment/myapp`, Helm : `helm rollback myrelease 1`) ; (2) Git revert + redeploy — git revert le commit, push, CI/CD redeploy ; (3) Database migration rollback — exécuter down migration (risky si data perdue, préférer backward-compatible migrations) ; (4) Feature flag — disable feature instantly without code rollback ; (5) Traffic shifting — load balancer rerouter vers Blue (previous version) en Blue/Green ; (6) Snapshot restore — pour stateful workloads, restore snapshot pré-incident.

Défis : (1) database schema changes irréversibles — solution : expand-contract pattern (additive migrations) ; (2) data writes incompatibles — solution : backward-compatible serialization, schema versioning ; (3) external state (sent emails, charged credit cards) cannot be rolled back ; (4) coordination multi-service rollback (microservices) — service A v2 attend service B v2 APIs, rollback A but not B = breakage.

Best practices : (1) automated rollback on health check failure (Argo Rollouts, CodeDeploy alarms-based) ; (2) feature flags pour instant kill switch ; (3) backward-compatible migrations rule ; (4) practice rollbacks regularly (game days) ; (5) document rollback procedures in runbooks ; (6) tested rollback paths in staging. Mature orgs : rollback completes in <5 minutes.