15-10-2018, 01:38 PM
Ouep, mais plusieurs points me gênent dans cette approche:
1) On doit faire soi-même le script de diff de migration, et le script de "défaisage" => on travaille donc par transition, et si jamais la BDD a dérivé de ce qui était prévu, il sera impossible de remonter le projet
2) Remonter le projet de 0 sera très chiant et long si les scripts de migration se sont accumulés
3) Impossible de retrouver pourquoi quelqu'un a rajouté telle colonne dans une table, sans devoir se palucher tous les scripts de migration pour essayer de comprendre
4) Si le script de migration a planté en plein milieu, quelle est la probabilité pour que le script de dé-migration fonctionne réellement, sachant qu'on est dans un état inconnu (vu que la migration a planté)?
5) On est quand même down pendant l'exécution de la migration SQL
Du coup, c'est pour ça que j'ai préféré l'approche: je crée un fichier par table/trigger/function/procedure qui crée cet élément SQL, je le charge dans une BDD vide (celle de "test"), puis je compare la BDD de test et la BDD de prod, j'en tire un diff SQL et je le lance sur cette BDD de prod, s'il foire, je recommence mon diff et mon éxécution jusqu'à ce que ça passe (ou jusqu'à ce que la 1ere ligne du diff plante ou que le diff soit considéré comme 'tournant en rond', auquel cas l'intervention manuelle sera probablement requise)
Mais bon, l'un dans l'autre, en utilisant des scripts de migration/démigration ou en faisant le diff automatiquement entre la BDD de prod et une BDD de test, j'ai le même "problème" (en fait, pas critique du tout, mais pour le principe) de "downtime": entre le moment où la migration SQL est lancée et le moment où elle est finie avec succès, le jeu est down. Je ne sais pas s'il existe des approches pour l'éviter sans perdre de données?!
1) On doit faire soi-même le script de diff de migration, et le script de "défaisage" => on travaille donc par transition, et si jamais la BDD a dérivé de ce qui était prévu, il sera impossible de remonter le projet
2) Remonter le projet de 0 sera très chiant et long si les scripts de migration se sont accumulés
3) Impossible de retrouver pourquoi quelqu'un a rajouté telle colonne dans une table, sans devoir se palucher tous les scripts de migration pour essayer de comprendre
4) Si le script de migration a planté en plein milieu, quelle est la probabilité pour que le script de dé-migration fonctionne réellement, sachant qu'on est dans un état inconnu (vu que la migration a planté)?
5) On est quand même down pendant l'exécution de la migration SQL
Du coup, c'est pour ça que j'ai préféré l'approche: je crée un fichier par table/trigger/function/procedure qui crée cet élément SQL, je le charge dans une BDD vide (celle de "test"), puis je compare la BDD de test et la BDD de prod, j'en tire un diff SQL et je le lance sur cette BDD de prod, s'il foire, je recommence mon diff et mon éxécution jusqu'à ce que ça passe (ou jusqu'à ce que la 1ere ligne du diff plante ou que le diff soit considéré comme 'tournant en rond', auquel cas l'intervention manuelle sera probablement requise)
Mais bon, l'un dans l'autre, en utilisant des scripts de migration/démigration ou en faisant le diff automatiquement entre la BDD de prod et une BDD de test, j'ai le même "problème" (en fait, pas critique du tout, mais pour le principe) de "downtime": entre le moment où la migration SQL est lancée et le moment où elle est finie avec succès, le jeu est down. Je ne sais pas s'il existe des approches pour l'éviter sans perdre de données?!