Synchronisation de la base de données entre dev / staging et production

J'ai un problème avec la synchronisation de la base de données WordPress entre développement et production et je me demande comment d'autres personnes le résolvent. Je suis conscient de cette question, mais elle ne couvre pas vraiment le cas d'utilisation plus sordide et plus réaliste.

Dites que j'ai un site Web WordPress en direct. J'ai pris une décharge de tout, en le répliquant sur notre environnement de développement. J'ai commencé à faire des changements. Une semaine plus tard, je suis prêt à déployer mes mises à jour. Dans l'intervalle, la base de données sur le site de production a changé (nouveaux messages, nouveaux commentaires, etc.). Comment synchroniser les modifications entre la production et le développement au cours du déploiement et est-il possible d'automatiser (au moins un peu) ce processus?

Il y a peut-être un meilleur moyen qui me manque, mais je vais vous donner 2 options:

1.Utilisez XML Export pour exporter vos nouveaux messages et commentaires. Ensuite, utilisez WordPress Importer pour importer les nouveaux articles et commentaires dans la base de données dev.

Il est préférable d'importer dans dev, puis de déplacer la base de données vers la production car, lors de l'importation, elle téléchargera tous les nouveaux fichiers multimédias de la production.

Entre temps, la production a changé (nouveaux messages, nouveaux commentaires, etc.)

Cela résoudrait votre problème de modification du contenu.

2. Utilisez la commande INSERT IGNORE INTO MySql pour ajouter les nouvelles tables de dev. ou la commande REPLACE pour écraser les lignes en double dans la même table.

Avant d’utiliser MySql, effectuez une sauvegarde des deux bases de données et déplacez la base de données gz sur le serveur de production, puis chargez le dump (changez le nom de dev s’il est identique à production.

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

Je ne suis pas à l'aise avec les commandes MySql, je choisirais donc l'option 1.

S'il s'agit simplement d'un type de données exactement identique (certains nouveaux messages de blog, de nouveaux commentaires), je ne suis pas sûr de savoir pourquoi vous devez vraiment le synchroniser. Ce n'est pas comme si cela allait changer la façon dont le code sur le site fonctionne, car c'est un peu la même chose. Je ne m'inquiète généralement pas à ce sujet, sauf s'il s'agit d'un nouveau type de données.

Je m'assure toujours de disposer d'un bon échantillon des données du site, pas toutes les publications, pages, commentaires du site en direct.

Dès que vous touchez le sujet des modifications en parallèle, vous touchez le domaine de la gestion de la configuration. Avec beaucoup de patterns, propres communautés (http://www.cmcrossroads.com/) et outils, pas tant pour la gestion de version (comme svn / git), mais pour le support de la gestion de configuration (patterns) comme clearcase. (zones totalement différentes).

Dans ce cas, la situation est toujours simple et vous constaterez que cela fonctionne avec certaines limitations, du travail manuel et des listes.

Le scénario auquel je pense doit être plus descriptif de la solution idéale: plusieurs développeurs travaillant sur la même base de code, plusieurs environnements de test, plusieurs environnements d'acceptation, plusieurs environnements d'acceptation de production éventuellement aux quatre coins du monde.

Si vous voulez faire cela un peu plus professionnel:

a) écrivez une liste de tous les éléments de configuration que vous rencontrez; il peut s’agir du code WordPress lui-même, des plugins provenant d’externaux, du contenu, des métadonnées et décidez lequel de ceux-ci vous souhaitez placer sous une sorte de "gestion", lesquels importent.

b) décrire les flux de travail qui peuvent survenir, par exemple ce qui se passe avec un correctif, ce qui se passe avec quelque chose de nouveau en cours de développement, dans quel cas changez-vous le contenu de votre côté, comment s'appelle-t-il, et qui le fait, qui en est le propriétaire par exemple un nouveau post ou un nouveau plugin.

c) pour le travail en parallèle, décrivez d’abord les CI que vous souhaitez gérer, puis décidez si le flux va toujours du développement à la production ou s’il est vraiment nécessaire de le faire de deux manières différentes.

d) pour chaque type de CI sous (a), écrivez une résolution. Par exemple, pour ALL, il s'agit d'un texte (ou d'un texte exporté tel que des fichiers php mais AUSSI du texte brut dans des fichiers XML), la fusion est possible. Ce n'est vraiment pas un problème mais vous avez besoin d'un bon outil de fusion. Par exemple, avec ClearCase, vous obtiendrez une fusion à 3 voies dans les situations suivantes: 1) des fusions triviales: il les fera automatiquement 2) non automatique automatique: il les fera automatiquement MAIS vous devez le vérifier 3) non trivial non automatique: est un conflit, par exemple sur une ligne, plusieurs modifications ont été apportées. Les éléments non triviaux sont la partie minimale dont vous devez vous occuper manuellement. Un bon outil de fusion vous guidera, par exemple celui de Clearcase (qui fusionne également des mots et permet de lier d'autres fusions commerciales ou non commerciales pour un fichier spécifique). les types). De plus, si vous avez identifié sous (a) des fichiers qui doivent être copiés uniquement, leur comportement sera de ne pas être fusionné mais simplement copié d’une manière qui écrase l’autre version sans fusion (par exemple, des plugins que vous n’avez pas modifié). Beaucoup de ces types sont possibles avec différents comportements. Mais écrivez les relations entre les CI,

Ensuite, pour les fusions non textuelles, vous devez décider comment les gérer, par exemple des images qui ont été modifiées à deux endroits. Vous pouvez décider ici que la production a toujours une préférence (du moins c'est ce que je pense), ce qui la rend simple.

Donc ... pour résoudre ce problème, vous avez besoin d'un outil de gestion de version qui prend en charge différents flux. Chaque flux représenterait une partie. (Cela peut être extrêmement complexe en fonction de vos besoins, mais dans ce cas, je pense que c'est très simple).

Si vous parvenez maintenant à avoir ces flux sous vos installations WordPress et à les synchroniser également avec le contenu de la base de données, etc., vous pouvez alors effectuer les fusions dans l'outil de gestion des versions / CM, puis l'exporter dans l'autre environnement.

La chose est ... vous devez écrire ceci en premier. Ce n'est pas un hack technique. C'est un modèle par défaut autour de la gestion de la configuration, donc rien d'étrange ici aussi, mais vous devez l'écrire. Vous pouvez par exemple constater qu'un plug-in installé apporte des modifications à la base de données avec des données différentes dans un autre environnement. Vous devez donc prévoir une procédure supplémentaire à ce sujet.

Techniquement, presque toujours, tout est possible. Consultez http://www.cmcrossroads.com/forums pour des scénarios qui sont des dizaines ou des centaines de fois plus complexes, tout en utilisant toujours la même approche et en utilisant le même ensemble de modèles CM.

en bref: placez une couche de gestion de versions, automatisez les fusions et gérez les conflits, puis importez dans l'environnement cible. Imaginez une stratégie de flux qui convient ici et écrivez-la. Effectuer une gestion minuscule très petite CM. Ce serait la solution professionnelle, sinon installez une copie de la copie de base de données, des scripts, etc.

Je viens de publier un article sur la synchronisation des données de production avec notre mise en scène. Consultez mon article à ce sujet à l' adresse suivante : http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database. de la production à la mise en scène /

Si vous souhaitez également synchroniser le code et d'autres éléments, je vous recommande de créer un référentiel git ou mercurial avec le fichier ignore correspondant.

Si vous souhaitez effectuer des mises à jour différentielles de prod à partir de staging, la création de scripts de migration est le moyen le plus sûr et le mieux.