Migrations et secrets en déploiement

Prérequis : cours 4.3 (migrations) et 5.1 (pipeline).

Pourquoi

Le déploiement échoue le plus souvent à deux endroits : le schéma (migration plantée à mi-chemin) et les secrets (variable manquante). Les deux se traitent avant de basculer le trafic (de rediriger les users vers la nouvelle version), avec des garde-fous automatiques.

Concepts

• Idempotent : rejouable sans effet. Grâce à schema_migrations, relancer les migrations ne réapplique rien : un échec se rejoue sereinement.
• Ordre de déploiement : pull → migrate → up -d → preuves. Si la migration échoue, on s'arrête : l'ancien code tourne toujours sur l'ancien schéma.
• Secrets exigés : l'app refuse de démarrer sans ses variables (${VAR:?message} dans compose, check au boot). Mieux vaut un crash immédiat et explicite qu'un comportement bizarre à 3h du matin.

Exemple : le contrat secrets

• .env.example versionné = la liste des noms (la doc).
• .env / .env.prod sur le serveur = les valeurs (600, jamais dans git).
• Rotation : générer → déployer partout → vérifier → révoquer l'ancien → confirmer dans les logs. Un secret qu'on ne sait pas changer est une bombe.

Cas réel

Variable SESSION_SECRET oubliée en prod : l'app démarre, les logins échouent un par un avec des erreurs cryptiques, 45 minutes pour comprendre. Avec check au boot : crash immédiat, message clair, 2 minutes.

Pièges

• Migration lancée après up -d : le nouveau code tourne sur l'ancien schéma → 500.
• .env.prod copié depuis .env.dev « pour aller vite » : mots de passe identiques dev/prod.
• Annoncer « déployé » sans les 3 voyants (docker ps healthy, curl public, appel métier — une requête qui exerce la vraie logique, pas un ping).

À retenir

Migrer avant de basculer, secrets exigés au boot, 3 voyants verts, déployer quand on peut surveiller 30 min.