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 les autres personnes le résolvent. Je suis conscient de cette question mais cela 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 le 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 ne s'agit que du même type de données (nouveaux messages de blog, 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 veille toujours à avoir un bon échantillon des données du site, pas toutes les publications, pages, commentaires du site en direct.
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: http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite -database-from-production-to-staging-enviorment/
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, alors je suppose que la création de scripts de migration est le moyen le plus sûr et le meilleur.
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 qu’elle 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 lesquels vous voulez placer sous une sorte de "gestion", lesquels sont importants.
b) décrire les flux de travail pouvant survenir, 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, 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.
d) pour chaque type de CI sous (a), écrivez une résolution. 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) fusions triviales: il les fera automatiquement 2) non automatiques simples: il les fera automatiquement MAIS vous devez le vérifier 3) non triviales non automatiques: c’est 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 Word 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 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. 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 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 configuration, donc rien d'étrange ici aussi, mais vous devez le noter. Vous pourriez trouver par exemple qu'un plug-in installé apporte des modifications dans 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 http://www.cmcrossroads.com/forums pour des scénarios qui sont des dizaines, voire 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-y une couche de gestion de versions, automatisez les fusions et gérez les conflits, puis importez-les 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.