Skip to main content

​
Où elles tournent

Les migrations sont appliquées par le pipeline de déploiement, jamais par l’image au démarrage. Le job migrate de deploy-api.yml tourne avant le flip d’image, et est sérialisé par job concurrency sur le stage. Le runner atteint Postgres via l’accès public restreint à la CIDR du migration runner (voir Infrastructure).

​
Le piège du rollback

Une migration destructive casse le rollback : l’ancienne image cherche une colonne disparue.

​
La règle : expand / contract

À tout instant, l’ancienne et la nouvelle image doivent fonctionner avec le schéma en place.
L’image précédente plante instantanément. Aucun rollback possible.

​
Règles pratiques

  • Toujours générer une migration quand le schéma bouge : yarn workspace @kare/database migrate:dev --name <description>.
  • Ne jamais éditer une migration déjà commitée.
  • Les migrations de données vivent dans apps/api/database/data-migrations/, comme scripts autonomes.
  • Une base restaurée depuis un dump ne fait pas reculer les images : après une restauration, vérifier que les containers tournent sur une image compatible.