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

34

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 les autres personnes le résolvent. Je connais 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?

    
posée Alex 22.09.2010 - 15:18
la source

4 réponses

9

Il y a peut-être un meilleur moyen de me manquer mais je vais vous donner 2 options:

1.Utilisez XML Export pour exporter vos nouveaux messages et commentaires. Utilisez ensuite l’ importateur WordPress 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 son importation, tous les nouveaux fichiers multimédias seront téléchargés de la production.

  

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

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

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 de 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 à celui de 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.

    
réponse donnée Chris_O 23.09.2010 - 03:45
la source
2

S'il s'agit simplement d'un type de données exactement identique (certains nouveaux billets 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, les pages, les commentaires du site actif.

    
réponse donnée curtismchale 22.09.2010 - 16:21
la source
1

Dès que vous abordez 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 souhaitez 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", ceux qui comptent.

b) décrivez les flux de travail pouvant se produire, par exemple. que se passe-t-il avec un correctif, que se passe-t-il 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, déterminez si le flux va toujours du développement à la production ou s’il est vraiment nécessaire de le faire de deux manières.

d) écrivez une résolution pour chacun des types de CI sous (a). Par exemple. pour TOUS c'est du texte (ou du texte exporté comme des fichiers php mais ÉGALEMENT 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) automatique non trivial: il les fera automatiquement MAIS vous devez le vérifier  3) non trivial non automatique: il s'agit d'un conflit, par exemple. sur 1 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 dans cet exemple. celui de Clearcase (qui effectue également la fusion de mots et permet de lier d'autres fusions commerciales ou non commerciales pour des types de fichiers spécifiques). 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 des comportements différents. Mais écrivez les relations entre les CI,

Ensuite, pour les fusions non textuelles, vous devez décider comment les gérer, par exemple. images qui ont été changées à 2 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 les exporter à nouveau dans le dossier. autre environnement.

La chose est ... vous devez d'abord l'écrire. 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 pourriez trouver par exemple 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 tout est possible, vérifiez enlace pour des scénarios qui sont des dizaines ou des centaines de fois plus complexes, tout en utilisant la même approche. et en utilisant le même ensemble de modèles CM.

en bref: placez-y une couche de gestion de versions, automatisez les fusions et gérez les conflits, puis importez-les dans un 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 du piratage de copie de base de données, des scripts, etc.

    
réponse donnée edelwater 14.11.2010 - 22:55
la source
1

Je viens tout juste 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: enlace

Si vous souhaitez 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, alors je suppose que la création de scripts de migration est le moyen le plus sûr et le meilleur.

    
réponse donnée Niklas 06.01.2012 - 00:21
la source

Lire d'autres questions sur les étiquettes