Plusieurs développeurs/éditeurs travaillant sur un site en cours
Contexte
Je suis sur le point de terminer la construction de mon premier site WordPress assez volumineux et je rencontre maintenant des frictions. Pour la plupart, le site a été développé sur mon ordinateur local et je voudrais transmettre les modifications à un serveur de transfert pour révision ( voir cette question pour plus d'informations ). La solution à laquelle j’ai abouti a plutôt bien fonctionné alors que j’étais en train de modifier du contenu, mais certaines personnes le modifient alors que j’ai encore des fonctionnalités à ajouter. L'idée était la suivante: nous pourrions faire avancer les choses plus rapidement si les fonctionnalités et le contenu étaient réunis en concert ... mais maintenant, je n'en suis pas si sûr.
Actuellement, la base de données contient un contenu différent de celui de mon ordinateur local sur le serveur de transfert. C'est très bien en soi, car je n'ai pas besoin de la copie finale du corps sur ma machine locale, mais je dois faire plus de développement qui affectera la base de données (installer/écrire quelques autres plugins qui ont besoin de leurs propres tables).
Ma question est la suivante:
Existe-t-il un moyen simple d’automatiser la fusion des bases de données afin que plusieurs personnes puissent travailler sur une installation WordPress? Bien sûr, je pourrais simplement exporter les tables que je sais ai modifiées sur ma machine locale et les transmettre au serveur de transfert, mais il est également possible que certains éléments de ce serveur de sauvegarde soient apportés. vers le bas. Je pourrais récupérer 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 existe un moyen accepté par la communauté de gérer ce genre de chose.
Merci!
J'ai posé cette question il y a plus d'un an. Au cours de cette période, nous avons ajouté plus de personnes à notre équipe et développé un nombre beaucoup plus important de sites dans WordPress. Je voulais parcourir notre processus au cas où cela pourrait aider quelqu'un d'autre.
Tout à Git
C’était quelque chose que je faisais alors même que je posais la question, mais c’est bien d’appeler ce point. L'utilisation de Git nous a non seulement aidés à être plus productifs, mais a également permis de sauver notre âne collectif à plusieurs reprises.
Avez-vous déjà eu besoin de procéder à des rénovations structurelles majeures sur un site, à obtenir l'approbation d'un client pour ces rénovations et à apporter des modifications mineures à la version non rénovée? Nous avons, et Git nous a laissé faire. Décrire cette configuration serait un peu long, mais en gros, 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. Cela nous permet bien sûr d’annuler les modifications, ce qui est excellent, 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 a fonctionné il y a un an? Peut-on le ramener?", La réponse est oui, même si la personne à qui on le demande ne participait pas à ce projet par an depuis.
Outre ces points, cela signifie également que nous ne sommes jamais bloqués sans les fichiers dont nous avons besoin. Nous pouvons toujours télécharger la version la plus récente du site à partir de n’importe quelle machine et commencer à apporter des modifications.
Utiliser Git pour déployer
Nous faisons notre hébergement WordPress sur Media Temple , et nous les aimons vraiment. Ils ne sont pas les fournisseurs les moins chers, mais leur service est excellent et leurs serveurs sont vraiment bien installés. Le fournit également Git par défaut. Cela signifie que nous pouvons configurer le serveur en tant que référentiel Git et extraire les modifications de cette manière au lieu d'utiliser SFTP. Cela signifie également que les travaux sur le serveur ne risquent pas d'être écrasés (ces modifications pouvant simplement être fusionnées et repoussées).
Étant donné que nous utilisons BitBucket en tant qu'hôte Git, un peu de travail supplémentaire est nécessaire. Tout d’abord, nous utilisons .ssh/config files pour pouvoir taper des éléments tels que ssh sitename afin de vous connecter à nos serveurs (nous utilisons également passwordless SSH , ce qui facilite grandement les choses). Nous nous assurons également de toujours utiliser mots de passe ssh (Mac OS X facilite cela très facilement en , ce qui vous permet de stocker votre mot de passe composé dans Keychain.app ). Enfin, nous ajoutons la ligne ForwardAgent à l'entrée .ssh/config sur les hôtes dont 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 garder le répertoire .git un répertoire au-dessus du répertoire HTML public.
Dumps automatisés de bases de données
Une fois le serveur en mode de production, nous nous assurons de sauvegarder automatiquement notre base de données, au cas où .
Tout le monde a sa propre wp-config
Parce que nous avons tous nos propres noms d'utilisateur et mots de passe de base de données locale et que nous pouvons utiliser différents noms et mécanismes de service, nous conservons chacun notre propre fichier wp-config. Chacun de ceux-ci est stocké dans Git avec un nom tel que wp-config-gavin.php, et lorsque nous voulons utiliser cette configuration, nous symlink it to wp-config.php (qui est ignoré par Git avec .gitignore ).
Cela nous permet également de remplacer l’option siteurl dans la table de base de données wp_options comme suit:
define('WP_SITEURL', 'http://sitename.localhost');
define('WP_HOME', 'http://sitename.localhost');
Cela empêche WordPress de consulter la base de données pour connaître l'emplacement du serveur, ce qui signifie qu'il n'y a pas de différences étranges en termes d'emplacement entre les installations locales et les installations du serveur.
Une dernière remarque sur les fichiers wp-config.php: veillez à les stocker au-dessus du répertoire HTML public et à rendre les autorisations lues uniquement pour l’utilisateur Web . 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 je devais accepter, c’est que, lors de l’utilisation de WordPress, il n’existait aucun moyen efficace de "fusionner" les modifications apportées à 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.
Au cours du développement, une seule personne "possède" le site. Cette personne s’occupe généralement de la configuration (mise en place du pack d’hébergement, démarrage du projet Basecamp, découpage de la conception, etc.). Une fois que cette personne est à un point raisonnable, la sauvegarde de la base de données pour l'installation de WordPress est insérée dans Git. À partir de ce moment, toutes les personnes en développement utilisent cette sauvegarde de base de données et le propriétaire est le seul à apporter des modifications à la base de données.
Une fois que la construction du site est un peu 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 la base de données sur le serveur et les récupérer pour le développement et les tests locaux.
Ce processus n'est pas parfait. Il est toujours possible que quelqu'un ait besoin de modifier localement le backend WordPress pendant le développement, puis de le faire à nouveau en production. Cependant, nous avons trouvé ce genre de chose rare et ce processus fonctionne assez bien pour nous.
Je teste différentes solutions au même problème en ce moment. C'est certainement un problème.
Ma solution actuelle consiste à effectuer un vidage mysql local à l'aide de l'indicateur --skip-extended-insert. Je pense que cet indicateur provoque la génération d'une instruction insert record 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 datadump .sql résultant en utilisant Git ainsi que les fichiers source du site. Lorsqu'un autre développeur supprime les modifications de code, le fichier .sql le suit. 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, en utilisant MAMP. Il n'est donc pas nécessaire d'effectuer une recherche ou un 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 un changement de base de données. Avant de faire quoi que ce soit dans Wordpress qui modifie la base de données, je m'assure qu'il a vérifié son dernier dump, extrait-le et l'importe, puis que je ne lui demande pas de modifier la base de données tant que je n'ai pas effectué et vérifié le mien. Ce n’est évidemment pas idéal et je cherche une meilleure solution mais c’est un début. Il nous donne également le contrôle de version de la base de données qui est Nice.
Je pourrais finir par nous installer 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 tunneling SSH. Cette approche rencontrera toutefois des problèmes chaque fois que l’un de nous installera un plugin. Fondamentalement, les fichiers PHP et la base de données MySQL ne seront pas synchronisés.
Je suis impatient d'entendre comment d'autres traitent ce problème.
Je travaille sur une telle installation et j'ai répondu aux questions comme celle-ci avant . Vous trouverez ci-dessous ma configuration préférée pour ce type de travail. Parce que vous voulez fusionner des bases de données au lieu de remplacer une base de données existante, j'ajouterais à cela une mise en garde de ne pas utiliser --add-drop-table flag lors du dump de 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 le nouveau: (1) Copiez le script ci-dessous. (2) chmod +x it. (3) Exécutez-le.
Utilisation: ./script.sh development-dump.sql > production-dump.sql
#!/bin/sed -f
s/'\([^\\']*\)development.domain.com\([^\\']*\)'/'\1production.domain.com\2'/g