La réalité est que ce que nous voulons est le suivant: http://www.liquibase.org/
Liquibase est une bibliothèque open source (licence Apache 2.0) indépendante de la base de données pour le suivi, la gestion et l'application des modifications de la base de données. Il repose sur une prémisse simple: toutes les modifications de la base de données sont stockées sous une forme lisible mais traçable par l'homme et archivées dans le contrôle de code source.
Cependant, notre processus de développement ne le prend pas en charge. Nous ne modifions généralement pas la base de données via des scripts discrets que nous écrivons nous-mêmes, nous utilisons des plugins que nous activons. Nous n'écrivons pas de scripts DML pour modifier les données de recherche que nous vérifions ensuite dans le contrôle du code source, nous utilisons une interface utilisateur sur la page d'administration et n'avons donc pas de code source pour une utilisation ultérieure dans la réplication de ce changement pendant la migration.
Cependant, nous pouvons en émuler une partie - en utilisant certains des outils répertoriés sur cette page:
/programming//q/225772/149060
Par exemple, liquidbase a une fonction de différenciation qui inclut également, en option, des modifications des données. Nous pourrions potentiellement produire le schéma et les données diff dans un script, en excluant (dans la mesure du possible) certaines tables susceptibles d'inclure des données de test (c'est-à-dire post, etc.) et ensuite appliquer le script à la base de données de production.
MySQLDiff (discuté sur la question StackOverflow) fait des différences de schéma, et son auteur recommande mysql_coldiff pour les différences de données par table - les deux sont implémentés en perl, si les outils java (liquidbase) sont trop lourds en ressources pour vos serveurs - bien que les deux bases de données soient locales et l'exécution de l'outil sur votre PC résout ce problème ...
Si nous voulons vraiment le faire correctement, nous devons consigner tout SQL qui se rapporte aux paramètres, options ou autres modifications de configuration et tout changement de schéma - et convertir le code enregistré en un script de migration à jouer sur notre serveur de production. Jouez le script de migration sur le serveur, copiez les fichiers du site wordpress (à l'exclusion des téléchargements, le cas échéant) et nous sommes en or.
Donc, il me semble que la meilleure solution est un plugin de migration-constructeur-développeur qui piège le sql dont nous avons besoin, le stocke puis génère un script de migration à partir du code enregistré, plutôt que de construire un moyen de fusionner des bases de données entre la mise en scène et la production. Semble un problème plus simple à résoudre aussi.
Si nous regardons le code du plugin d'appels de crochet d'instrumentation de @bueltge pour trouver l'inspiration: https://gist.github.com/1000143 (merci à Ron Rennick via G + de m'avoir pointé en direction de SAVEQUERIES et du crochet d'arrêt, cela amène-moi à le trouver)
- modifiez-le pour obtenir la sortie SAVEQUERIES à la place
- ne fonctionne que sous admin
- filtrer toutes les sélections
- enregistrer les résultats sur la table dans le crochet d'arrêt
- nous pourrions basculer sélectivement le piégeage de sortie en fonction de ce que nous faisions en ce moment.
Par exemple:
Nom de capture: activer et configurer le plug-in XYZ
Activer / désactiver l'état de capture - activé
... installer et configurer le plugin XYZ
Basculer l'état de capture - désactivé
Exporter le script de migration pour: activer et configurer le plug-in XYZ
Appuyez sur le bouton Export - pour produire un champ de texte contextuel avec le SQL filtré piégé - idéalement pré-formaté en tant que script shell avec appel en ligne de commande à mysql. Copiez et collez-le dans votre dossier de code de migration et ajoutez-le à votre référentiel de code source.
Une attention particulière à l'activation et la désactivation de la capture pendant que vous travaillez et vous serez en mesure de générer le script de migration parfait pour amener votre base de données de production dans une configuration équivalente à votre base de données intermédiaire.
Quoi de mieux, vous aurez un script (ou une série de mêmes) que vous pourrez tester. Imagerie ayant des scripts de migration réplicables et testables !!
Je suis déjà amoureux.
Quelqu'un d'autre?