Je pense qu'il y a deux parties à ce problème.
La première consiste à gérer le schéma de la base de données et ses modifications. Pour ce faire, nous utilisons South, en conservant à la fois les modèles de travail et les fichiers de migration dans notre référentiel SCM. Par sécurité (ou paranoïa), nous effectuons un vidage de la base de données avant (et si nous avons vraiment peur, après) l'exécution de toute migration. Le sud a été suffisant pour toutes nos exigences jusqu'à présent.
Deuxièmement, le déploiement du changement de schéma qui va au-delà de la simple exécution du fichier de migration généré par South. D'après mon expérience, une modification de la base de données nécessite normalement une modification du code déployé. Si vous avez même une petite ferme Web, maintenir la synchronisation du code déployé avec la version actuelle de votre schéma de base de données peut ne pas être trivial - cela s'aggrave si vous considérez les différentes couches de mise en cache et l'effet sur un utilisateur de site déjà actif. Différents sites gèrent ce problème différemment, et je ne pense pas qu'il existe une réponse unique.
Résoudre la deuxième partie de ce problème n'est pas nécessairement simple. Je ne crois pas qu'il existe une approche unique et il n'y a pas suffisamment d'informations sur votre site Web et votre environnement pour suggérer une solution qui serait la plus adaptée à votre situation. Cependant, je pense qu'il y a quelques considérations qui peuvent être gardées à l'esprit pour aider à guider le déploiement dans la plupart des situations.
Mettre l'ensemble du site (serveurs Web et base de données) hors ligne est une option dans certains cas. C'est certainement le moyen le plus simple de gérer les mises à jour. Mais des temps d'arrêt fréquents (même lorsqu'ils sont planifiés) peuvent être un bon moyen de mettre fin à nos activités rapidement, rendent fastidieux le déploiement de modifications de code, même minimes, et peuvent prendre plusieurs heures si vous avez un ensemble de données volumineux et/ou une migration complexe. Cela dit, pour les sites que j'aide à gérer (qui sont tous internes et généralement utilisés uniquement pendant les heures de travail les jours ouvrables), cette approche fonctionne à merveille.
Soyez prudent si vous effectuez les modifications sur une copie de votre base de données principale. Le principal problème ici est que votre site est toujours en ligne et accepte probablement les écritures dans la base de données. Qu'arrive-t-il aux données écrites dans la base de données master pendant que vous êtes en train de migrer le clone pour une utilisation ultérieure ? Votre site doit soit être en panne tout le temps, soit être mis temporairement dans un état de lecture seule, sinon vous le perdrez.
Si vos modifications sont rétrocompatibles et que vous disposez d'une batterie de serveurs Web, vous pouvez parfois mettre à jour le serveur de base de données de production en direct (ce qui, à mon avis, est inévitable dans la plupart des situations), puis mettre à jour progressivement les nœuds de la batterie en les retirant du équilibreur de charge pendant une courte période. Cela peut fonctionner correctement - mais le principal problème ici est que si un nœud qui a déjà été mis à jour envoie une demande pour une URL qui n'est pas prise en charge par un nœud plus ancien, vous échouerez car vous ne pouvez pas gérer cela au niveau de l'équilibreur de charge.
J'ai vu/entendu quelques autres façons de bien fonctionner.
La première consiste à envelopper toutes les modifications de code dans un verrou de fonctionnalité qui est ensuite configurable au moment de l'exécution via certaines options de configuration à l'échelle du site. Cela signifie essentiellement que vous pouvez publier du code où toutes vos modifications sont désactivées, puis après avoir effectué toutes les mises à jour nécessaires sur vos serveurs, vous modifiez votre option de configuration pour activer la fonctionnalité. Mais cela fait du code assez lourd...
La seconde est de laisser le code gérer la migration. J'ai entendu parler de sites où les modifications apportées au code sont écrites de manière à gérer la migration au moment de l'exécution. Il est capable de détecter la version du schéma utilisé et le format des données qu'il a récupérées - si les données proviennent de l'ancien schéma, il effectue la migration en place, si les données proviennent déjà du nouveau schéma, il ne fait rien . De l'utilisation naturelle du site, une grande partie de vos données sera migrée par les personnes utilisant le site, le reste vous pouvez le faire avec un script de migration quand vous le souhaitez.
Mais je pense qu'à ce stade, Google devient votre ami, car comme je l'ai dit, la solution est très spécifique au contexte et je crains que cette réponse ne commence à perdre son sens ... Recherchez quelque chose comme "déploiement sans temps d'arrêt" et vous ' obtiendrez des résultats tels que ceci plein d'idées...
