L'un dans l'autre, ça revient au même, mais qu'en est-il de l'exécution de ces scripts? Parce que leur origine, bon, je pourrai sauver & commiter le diff généré (j'en vois pas l'intérêt du tout franchement, je trouve qu'il a juste sa place dans les logs et c'est tout) mais partant de ces scripts de migrations, comment ces outils gèrent-il les downtime et l'application de la migration sur le SQL?
Parce que le patch du SQL et le patch du serveur web ne peuvent pas être faites "pile poil en même temps et en 0 secondes", donc y'aura forcément une période où soit le SQL sera "trop" à jour (le code web est en retard de version) soit l'inverse, le SQL n'est pas encore à jour alors que le code web l'est... Et comme la migration SQL n'est pas instantanée (surtout si elle a chié), y'a forcément un "trou" pendant lequel le jeu est bloqué?
Mantis a l'air de procéder ainsi (mise en "offline" pendant la durée de la mise à jour).
Wordpress, je ne sais pas trop...
Vous avez d'autres exemples/pistes/réponses en tête sur ce point-là?
@Ter Rowan Si ce n'est pas toi qui te charge de ça, est-ce que celui/celle en charge de ces déploiement a une procédure que tu peux communiquer ou saurai répondre à la question si tu lui demandes?
Parce que bon, nous de notre côté au boulot, c'est "on déploie le code web d'un côté, on exécute le script de diff [forgé à la mano] de l'autre, et on croise les doigts pour que rien ne pète; et au cas par cas, soit on lance le SQL d'abord puis le web, soit l'inverse [suivant ce qui est le plus cassant]". Je trouve ça un peu... bof :/ Ca marche, certes, mais bof...
[edit]
Tiens, en revanche, cette histoire de diff de rollback etc me fait tilter que j'ai déjà une tâche de rollback en cas de foirage du déploiement: je reviens en arrière dans Hg sur le dernier commit déployé (un tag l'indique) et je relance le déploiement: le SQL s'alignera tout seul sur la structure qu'il avait à ce moment-là...
Parce que le patch du SQL et le patch du serveur web ne peuvent pas être faites "pile poil en même temps et en 0 secondes", donc y'aura forcément une période où soit le SQL sera "trop" à jour (le code web est en retard de version) soit l'inverse, le SQL n'est pas encore à jour alors que le code web l'est... Et comme la migration SQL n'est pas instantanée (surtout si elle a chié), y'a forcément un "trou" pendant lequel le jeu est bloqué?
Mantis a l'air de procéder ainsi (mise en "offline" pendant la durée de la mise à jour).
Wordpress, je ne sais pas trop...
Vous avez d'autres exemples/pistes/réponses en tête sur ce point-là?
@Ter Rowan Si ce n'est pas toi qui te charge de ça, est-ce que celui/celle en charge de ces déploiement a une procédure que tu peux communiquer ou saurai répondre à la question si tu lui demandes?
Parce que bon, nous de notre côté au boulot, c'est "on déploie le code web d'un côté, on exécute le script de diff [forgé à la mano] de l'autre, et on croise les doigts pour que rien ne pète; et au cas par cas, soit on lance le SQL d'abord puis le web, soit l'inverse [suivant ce qui est le plus cassant]". Je trouve ça un peu... bof :/ Ca marche, certes, mais bof...
[edit]
Tiens, en revanche, cette histoire de diff de rollback etc me fait tilter que j'ai déjà une tâche de rollback en cas de foirage du déploiement: je reviens en arrière dans Hg sur le dernier commit déployé (un tag l'indique) et je relance le déploiement: le SQL s'alignera tout seul sur la structure qu'il avait à ce moment-là...