La migration dangereuse n'est pas celle qui change le schéma. C'est celle qui suppose que chaque instance de l'application en cours d'exécution, chaque travailleur de tâche et chaque consommateur en arrière-plan changera d'attentes au même instant.
Cette hypothèse n'est presque jamais sûre en production.
Ce que signifie Étendre et Réduire
Le modèle fonctionne parce qu'il accepte le chevauchement entre l'ancien monde et le nouveau monde :
- étendre le schéma
- garder l'ancien code fonctionnel
- remplir ou écrire en parallèle
- changer les lectures et les écritures
- supprimer la forme héritée plus tard
Par exemple, passer de full_name à first_name et last_name commence généralement par une extension :
ALTER TABLE users ADD COLUMN first_name TEXT;
ALTER TABLE users ADD COLUMN last_name TEXT;
Ensuite, vous remplissez :
UPDATE users
SET first_name = split_part(full_name, ' ', 1),
last_name = substring(full_name from position(' ' in full_name) + 1);
Ce n'est qu'après que l'application peut lire en toute sécurité les nouvelles colonnes que vous supprimez full_name.
Pourquoi Ce Modèle Vaut Les Étapes Supplémentaires
Étendre et réduire est plus lent qu'une migration cassante en une seule fois, mais il gère mieux les vraies conditions de production :
- déploiements progressifs
- travaux en arrière-plan sur des versions plus anciennes
- tentatives sur des versions d'application mélangées
- remplissages partiels qui nécessitent une surveillance
Les étapes supplémentaires ne sont pas de la cérémonie. Ce sont elles qui vous achètent de la compatibilité pendant le changement.
Compromis
Le coût est une complexité temporaire :
- plus de chemins de code pendant un certain temps
- comptabilité de migration
- travaux de nettoyage ultérieurs
Les équipes rencontrent des problèmes lorsqu'elles réalisent la phase d'extension et oublient la phase de réduction. Si le chemin héritée n'est jamais supprimé, la migration devient une dette architecturale permanente.
Lectures Complémentaires