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.