Base de données Wordpress synchronisée entre dev et prod
Une question a déjà été posée sur la synchronisation des fichiers ainsi que sur la base de données entre deux installations Wordpress.
Au niveau de la base de données, la solution consiste généralement à vider une base de données et à l’insérer sur un autre serveur. Le problème, c’est que vous perdez toutes les modifications potentiellement apportées sur le serveur de production. Par exemple, mesures d'utilisation, commentaires, etc.
Dans cet esprit, je commençais à me demander s’il serait possible d’étendre le Wordpress ORM afin que vous puissiez générer des deltas puis les injecter dans le site de production.
Quelqu'un a-t-il essayé, examiné ou avez-vous des idées ou des commentaires?
La réalité est que ce que nous souhaitons, c'est ceci: http://www.liquibase.org/
Liquibase est une bibliothèque open source (sous licence Apache 2.0), indépendante de la base de données, permettant de suivre, gérer et appliquer les modifications apportées à la base de données. Il repose sur un principe simple: toutes les modifications de la base de données sont stockées dans un formulaire lisible, mais pouvant être suivi, et archivées dans le contrôle de source.
Cependant, notre processus de développement ne le supporte pas. Nous ne modifions généralement pas la base de données à l'aide de scripts discrets que nous écrivons nous-mêmes, nous utilisons des plug-ins que nous activons. Nous n'écrivons pas de scripts DML pour modifier les données de recherche que nous archivons ensuite dans le contrôle de code source, nous utilisons une interface utilisateur sur la page d'administration et ne disposons donc pas de code source pour une utilisation ultérieure lors de la réplication de cette modification lors de la migration.
Cependant, nous pouvons en émuler une partie - en utilisant certains des outils énumérés sur cette page:
https://stackoverflow.com/q/225772/149060
Par exemple, liquidbase a une fonctionnalité de diff qui inclut également éventuellement des modifications de données. Nous pourrions éventuellement exporter les différences de schéma et de données 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.), puis en appliquant le script à la base de données de production.
MySQLDiff (discuté à la question de StackOverflow) fait des différences de schéma, et son auteur recommande mysql_coldiff pour les différences de données en mode table - sont implémentées en Perl, si les outils Java (liquidbase) sont trop chargés en ressources pour vos serveurs - bien que apportez les deux bases de données en local et l'utilisation de l'outil sur votre PC résout ce problème ...
Si nous voulons vraiment bien faire les choses, nous devons consigner tout SQL qui se rapporte à des paramètres, des options ou d’autres modifications de configuration, ainsi que tout changement de schéma - et convertir le code enregistré en un script de migration à utiliser 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 voilà en or.
Donc, il me semble que le meilleur moyen de s'en sortir est le plugin de développement de constructeur de migration qui piège le SQL dont nous avons besoin, le stocke et génère ensuite un script de migration à partir du code enregistré, plutôt que de créer 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 plug-in de hooking instrumenting de @bueltge pour inspiration: https://Gist.github.com/1000143 (merci à Ron Rennick via G + pour m'avoir dirigé vers SAVEQUERIES et le crochet d'arrêt, qui m'a amené à le trouver)
- modifiez-le pour obtenir la sortie SAVEQUERIES à la place de - exécuté uniquement sous admin - filtre toutes les sélections - enregistrez les résultats dans le tableau dans le crochet d'arrêt - nous pourrions activer/désactiver le recouvrement des sorties en fonction de ce que nous étions en train de faire.
Par exemple:
Nom de capture: Activer et configurer le plugin XYZ
Capture State Toggle - sur
... installer et configurer le plugin XYZ
Capture State Toggle - off
Exporter un script de migration pour: Activer et configurer le plugin XYZ
Appuyez sur le bouton Exporter pour créer un champ de texte contextuel contenant le code SQL capturé et filtré. Idéalement, il est pré-formaté en tant que script Shell avec l'appel de la ligne de commande à mysql. Copiez-le et collez-le dans votre dossier de code de migration et ajoutez-le à votre référentiel de code source.
Si vous travaillez avec une attention particulière, vous pouvez générer le script de migration parfait pour amener votre base de production à une configuration équivalente à celle de votre base de données intermédiaire.
Quoi de mieux, vous aurez un script (ou une série de même) que vous pouvez tester. Imaging ayant des scripts de migration réplicables, testables, !!
Je suis déjà amoureux.
Quelqu'un d'autre?
Le pluginde base de données WordPress plugin synchronise les données entre deux serveurs.
Par défaut, il écrase TOUTES les données de destination. Cependant, je viens de mettre en œuvre certaines améliorations du plug-in, qui vous permettent de ne synchroniser que des tables de base de données spécifiques. Cela peut vous aider à conserver les commentaires, les utilisateurs et autres données que vous ne voulez pas écraser. Est-ce que cela vous donne la granularité dont vous avez besoin?
Je n'ai pas encore publié mes modifications au public, mais si une copie vous intéresse, envoyez-moi un courrier électronique à l'adresse 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.
UPDATE: Je viens également de trouver le plugin WP-Sync-DB , qui est un fork du commercial WP-Migrate-DB-Pro brancher. Il fait une chose très similaire, même s'il a probablement plus de raffinement que Database Sync.
Il existe un service commercial relativement nouveau spécifiquement dédié à cette tâche. Cela s'appelle RAMP:
http://alexking.org/blog/2011/07/20/ramp-content-deploy-wordpress