Synchronisation de base de données Wordpress entre dev et prod

Une question a déjà été posée sur la façon de synchroniser les fichiers ainsi que la base de données entre deux installations Wordpress.

Pour le niveau de la base de données, la réponse consiste généralement à vider une base de données et à l'insérer sur un autre serveur. Le problème avec cela est que vous finissez par perdre toutes les modifications qui ont potentiellement été apportées sur le serveur prod. Par exemple, les mesures d'utilisation, les commentaires, etc ...

Dans cet esprit, je commençais à me demander s'il serait possible d'étendre l'ORM Wordpress afin que vous puissiez générer des deltas puis les injecter dans le site de production.

Quelqu'un a-t-il essayé cela, y a-t-il étudié ou a-t-il des idées ou des commentaires?

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?

La base de données Sync plugin pour WordPress fait un excellent travail de synchroniser les données entre deux serveurs.

Par défaut, il écrase TOUTES les données de destination, mais je viens d'implémenter quelques améliorations au plugin qui vous permettent de synchroniser uniquement des tables de base de données spécifiques. Cela peut vous aider à conserver les commentaires, les utilisateurs et d'autres données de ce type que vous ne souhaitez pas écraser. Cela vous donne-t-il la granularité dont vous avez besoin?

Je n'ai pas encore rendu public mes changements, mais si vous êtes intéressé par une copie, envoyez-moi un e-mail à simon-at-yump.com.au. Si quelqu'un trouve cela utile ou a des demandes de fonctionnalités supplémentaires, faites le moi savoir et je verrai ce que je peux faire.

MISE À JOUR: Je viens également de trouver le plugin WP-Sync-DB , qui est un fork du plugin commercial WP-Migrate-DB-Pro . Il fait une chose très similaire, bien qu'il ait probablement plus de poli que Database Sync .

Il existe un service commercial relativement nouveau spécialement pour cette tâche. Cela s'appelle RAMP:

http://alexking.org/blog/2011/07/20/ramp-content-deploy-wordpress