Contexte

J'approche des étapes finales de la construction de mon premier site WordPress assez grand, et je rencontre maintenant des frictions. Pour la plupart, le site a été développé sur ma machine locale et je pousserais les modifications vers un serveur de transfert pour examen ( voir cette question pour plus d'informations ). La solution avec laquelle je me suis retrouvé a plutôt bien fonctionné quand il s'agissait juste de moi de modifier le contenu, mais maintenant, d'autres personnes modifient le contenu alors que j'ai encore des fonctionnalités à ajouter. L'idée était: nous pourrions faire avancer les choses plus rapidement si les fonctionnalités et le contenu se rejoignaient de concert ... mais maintenant je n'en suis pas si sûr.

Actuellement, le contenu de la base de données sur le serveur de transfert est différent de celui de ma machine locale. C'est bien en soi, car je n'ai pas besoin de la copie finale du corps sur ma machine locale, mais j'ai besoin de faire plus de développement qui affectera la base de données (installer / écrire quelques plugins supplémentaires qui ont besoin de leurs propres tables).

Ma question est:

Existe-t-il un moyen simple d'automatiser la fusion de bases de données afin que plusieurs personnes puissent travailler sur une installation WordPress? Je pourrais, bien sûr, simplement exporter les tables que je sais avoir changé sur ma machine locale et les pousser vers le serveur de transfert, mais il est possible qu'il y ait aussi des choses sur le serveur de transfert que je voudrais supprimer. Je pourrais saisir la sortie SQL des deux bases de données et les différencier ... mais cela semble fastidieux et hackish. Je me demande si c'est un problème que d'autres ont résolu; s'il y a une façon acceptée par la communauté de gérer ce genre de chose.

Merci!

J'ai posé cette question il y a plus d'un an, et pendant ce temps, nous avons ajouté plus de personnes à notre équipe et développé un plus grand nombre de sites dans WordPress. Je voulais parcourir notre processus au cas où cela pourrait aider quelqu'un d'autre.

Tout dans Git

C'était quelque chose que je faisais même quand je posais la question, mais c'est bon d'appeler ce point. L'utilisation de Git nous a non seulement aidés à être plus productifs, mais cela a également sauvé nos ânes collectifs à plusieurs reprises.

Avez-vous déjà eu besoin d'effectuer des rénovations structurelles majeures sur un site, d'obtenir l'approbation de ces rénovations d'un client et, tout en faisant des mises à jour mineures de la version non rénovée? Nous l'avons fait, et Git nous a laissé le faire. Décrire cette configuration serait un peu long, mais l'essentiel est que nous avons créé une nouvelle branche, tiré cette branche sur le serveur et attaché un sous-domaine à cette branche.

Nous avons également été sauvés par Git. Bien sûr, cela nous permet d'annuler les modifications, ce qui est génial, mais cela nous permet également de récupérer les anciennes versions des fichiers. Cela signifie que si un client demande: "Rappelez-vous comment cette partie du site fonctionnait il y a environ un an? Pouvons-nous le ramener?", La réponse est oui - même si la personne interrogée n'était pas sur ce projet un an depuis.

Outre ces points, cela signifie également que nous ne sommes jamais coincés sans les fichiers dont nous avons besoin. Nous pouvons toujours extraire la dernière version du site de n'importe quelle machine et commencer à apporter des modifications.

Utilisez Git pour déployer

Nous faisons notre hébergement WordPress sur Media Temple , et nous les aimons vraiment. Ce n'est pas le fournisseur le moins cher, mais leur service est excellent et leurs serveurs sont vraiment bien installés. Ils fournissent également Git par défaut. Cela signifie que nous pouvons configurer le serveur en tant que référentiel Git et tirer les modifications de cette manière au lieu d'utiliser SFTP. Cela signifie également que le travail sur le serveur ne risque pas d'être écrasé (car ces modifications peuvent simplement être fusionnées et repoussées).

Parce que nous utilisons BitBucket comme hôte Git, il y a un peu de travail supplémentaire requis ici. Tout d'abord, nous utilisons des fichiers .ssh / config afin de pouvoir taper des choses comme ssh sitenamese connecter à nos serveurs (nous utilisons également SSH sans mot de passe , ce qui rend cela très facile). Nous nous assurons également de toujours utiliser les phrases secrètes ssh (Mac OS X facilite cela en vous permettant de stocker votre phrase secrète dans Keychain.app ). Enfin, nous ajoutons la ligne a ForwardAgent à l'entrée .ssh / config sur les hôtes que nous voulons extraire. Cela signifie que nous n'avons besoin que de la clé publique SSH de chaque personne dans BitBucket, et non de la clé publique de chaque serveur. Nous nous assurons également de conserver le .gitrépertoire un répertoire au-dessus du répertoire HTML public.

Dumps de base de données automatisés

Une fois le serveur en mode production, nous veillons à sauvegarder automatiquement notre base de données, au cas où .

Chacun a sa propre configuration wp

Parce que nous avons tous nos propres noms d'utilisateur et mots de passe de base de données locale, et parce que nous pouvons utiliser des noms et des mécanismes de service différents, nous conservons chacun notre propre fichier wp-config. Chacun d' entre eux est stocké dans Git avec un nom comme wp-config-gavin.phpet quand on veut utiliser cette configuration, nous faites des liens symboliques à wp-config.php(qui est ignoré par Git en utilisant .gitignore ).

Cela nous permet également de remplacer l' siteurloption dans la wp_optionstable de base de données comme suit:

define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');

Cela empêche WordPress de regarder la base de données pour l'emplacement du serveur et signifie qu'il n'y a pas de différences étranges dans l'emplacement entre les installations locales et les installations de serveur.

Une dernière remarque sur les fichiers wp-config.php: assurez-vous de les stocker au-dessus du répertoire HTML public et de faire les autorisations en lecture seule pour l'internaute . Cela fait une énorme différence dans la sécurisation de WordPress.

Le problème de la base de données

Enfin, la viande de la matière.

Ce que j'ai dû accepter, c'est qu'en utilisant WordPress, il n'y a pas de bon moyen de «fusionner» les modifications de la base de données. Au lieu de cela, nous devions élaborer des règles de conduite pour résoudre ce problème. Les règles sont assez simples et nous ont bien servi jusqu'à présent.

Pendant le développement, il y a une seule personne qui "possède" le site. Cette personne fait généralement la configuration (rassembler le package d'hébergement, démarrer le projet Basecamp, découper la conception, ce genre de chose). Une fois que cette personne est à un point raisonnable, videz la base de données pour l'installation de WordPress et mettez-la dans Git. À partir de ce moment, tous ceux qui développent utilisent ce vidage de base de données, et le propriétaire est le seul à apporter des modifications à la base de données.

Une fois la construction du site un peu plus avancée, le site est placé sur un serveur. À partir de ce moment, la base de données du serveur est canonique. Tout le monde (y compris le propriétaire) doit apporter toutes les modifications de base de données sur le serveur et les retirer pour le développement local et les tests.

Ce processus n'est pas parfait. Il est toujours possible que quelqu'un doive apporter des modifications dans le backend WordPress localement pendant le développement, puis devoir effectuer ces modifications à nouveau en production. Cependant, nous avons trouvé ce genre de chose rare, et ce processus fonctionne assez bien pour nous.

Je travaille sur une telle installation et j'ai déjà répondu à des questions comme celle-ci . Ci-dessous est ma configuration préférée pour ce genre de travail. Parce que vous voulez fusionner des bases de données au lieu de remplacer une base de données existante, j'ajouterais à celles-ci une mise en garde de ne pas utiliser l' indicateur --add-drop-table lors de l' exécution du vidage MySQL.

• Étape 1. Mysqldump votre base de données de développement
• Étape 2. Remplacez toutes les instances de development.domain.com par production.domain.com ^^
• Étape 3. Connectez-vous à MySQL, exécutez une commande SOURCE pour importer des données, par exemple source /path/to/file

^^ Comment remplacer toutes les instances de l'ancien domaine par un nouveau: (1) Copiez le script ci-dessous. (2) chmod +x. (3) Exécutez-le.

Usage: ./script.sh development-dump.sql > production-dump.sql

#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g

J'expérimente avec différentes solutions à ce même problème en ce moment. C'est certainement délicat.

Ma solution actuelle est de faire un vidage mysql local en utilisant le drapeau --skip-extended-insert. Je crois que cet indicateur provoque la génération d'une instruction d'insertion d'enregistrement pour chaque ligne de la base de données, ce qui rend le vidage un peu plus convivial. J'ai repris cette astuce dans cet article: http://www.viget.com/extend/backup-your-database-in-git/ .

Je contrôle ensuite le fichier de vidage de données .sql résultant à l'aide de Git avec les fichiers source du site. Lorsqu'un autre développeur supprime les modifications de code, le fichier .sql est fourni avec lui. Il importe ensuite ce fichier dans sa version locale de la base de données. Nous avons tous deux configuré nos bases de données locales respectives de la même manière sur les deux machines, à l'aide de MAMP, il n'est donc pas nécessaire d'effectuer de recherche ni de remplacement.

Il y a eu des problèmes de fusion, nous essayons donc d'adopter une approche "à tour de rôle" pour tout ce qui entraînera une modification de la base de données. Avant de faire quoi que ce soit dans Wordpress qui changera la base de données, je m'assure qu'il a vérifié dans son dernier vidage, le tire et l'importe, et je lui demande de ne pas apporter de modifications à la base de données avant d'avoir fait et vérifié le mien. Ce n'est évidemment pas idéal et je cherche une meilleure solution mais c'est un début. Cela nous donne également un contrôle de version de la base de données, ce qui est bien.

Je peux finir par nous configurer une base de données de développement partagée sur le serveur et essayer de connecter nos deux copies locales du site Web à la même base de données via le tunnel SSH. Cette approche, cependant, rencontrera des problèmes chaque fois que l'un de nous installera un plugin. Fondamentalement, les fichiers PHP et la base de données MySQL seront désynchronisés.

J'ai hâte de savoir comment les autres gèrent ce problème.