WordPress et Git Workflow

Je sais que cette question a été posée mille fois, mais j'essaie vraiment de savoir comment tirer le meilleur parti de Git lorsque vous travaillez avec WordPress.

J'ai parcouru le Web et lu des dizaines d'articles, qui semblent couvrir brièvement le sujet. Voici quelques-uns des plus remarquables que j'ai lus récemment.

- Version contrôlant WordPress

- Gestion des déploiements de thèmes WordPress avec Git

- Gérez votre thème WordPress personnalisé en utilisant git au lieu de FTP

Actuellement, mon flux de travail ressemble à ceci.

• Installez WordPress localement
• Développer un thème
• Exporter des bases de données WordPress depuis un serveur local
• Importer la base de données WordPress sur un serveur distant
• Téléchargez des fichiers WordPress et un thème via FTP
• Le client apporte des modifications
• Téléchargez les fichiers et le thème WordPress via FTP et exportez les bases de données WordPress depuis un serveur distant
• Remplacer les fichiers localement
• Apportez des modifications au développement
• Re-télécharger via FTP, exporter et importer la base de données sur le serveur distant

Je me rends compte que Git peut rationaliser ce processus. Il semble que la meilleure façon de le faire soit d'avoir un fichier .gitignore qui ignore certains répertoires qui n'ont pas besoin d'être suivis, ainsi que d'avoir un fichier wp-config.php local et distant.

Mais comment gérez-vous les bases de données? Les clients apporteront généralement des modifications (publications / pages / plugins). Dois-je toujours exporter à partir de la base de données distante et réimporter sur mon serveur local?

Quelqu'un peut-il suggérer le meilleur flux de travail pour moi ici? Et guidez-moi à travers les étapes.

De plus, j'aimerais probablement utiliser Bitbucket car les dépôts privés avec eux sont gratuits, contrairement à GitHub.

Toute aide serait appréciée.

Merci d'avance!

Je suis l'un des développeurs de WP Migrate DB Pro et je voudrais répondre à la question de @ Ennui:

"Savez-vous si le script de remplacement d'url db qu'il exécute prend en compte les chaînes sérialisées?"

Oui, il gère les données sérialisées. En fait, c'est la principale raison pour laquelle j'ai développé la version gratuite du plugin en 2009. :)

Malheureusement, je n'ai qu'une réputation de 41, donc je n'ai pas pu répondre au commentaire de @ Ennui. Désolé.

Je suis à la limite du vote sur la clôture de ce projet de loi comme "non constructif" car il semble que ce soit le genre de choses qui solliciteront le débat et l'opinion plutôt que des réponses. Mais...

Ce n'est pas à quoi ressemble mon flux de travail, et cela rend mon approche (et ma réponse) différente de la plupart des autres réponses jusqu'à présent.

1. Installez WordPress localement
   1. Ceci est cloné à partir d'un dépôt Git nu local contenant la dernière version stable.
   2. Je garde également une copie locale de la dernière version de quelques plugins que j'installe presque toujours.
2. Construisez le thème et tous les plugins nécessaires
3. Téléchargement vers un serveur de transfert public
   1. Le client a accès mais ne peut pas changer le code et il a indiqué que les modifications de la base de données ne seront pas transférées sur le site de production.
   2. Cela signifie qu'il n'y a aucune raison de télécharger à nouveau le code sur le serveur de développement.
   3. Et aucune raison de resynchroniser la base de données locale
4. Apportez des modifications au site local en fonction de notre personnel et des commentaires du client.
5. Importer les modifications
6. Répétez si nécessaire (mais avec une résistance croissante :))
7. Si nous fournissons du contenu, ce qui n'est pas toujours le cas, nous (pas le client) nettoierons la base de données sur le serveur de transfert et téléchargerons le contenu.
8. Déployez en téléchargeant le code local sur le site de production.
9. Si nous avons créé du contenu, le contenu est exporté à partir du site de transfert via l'outil d'exportation vanilla et importé dans le site de production.
   1. C'est la seule fois où je dois déplacer la base de données, et cela se fait avec des outils assez standard. J'utiliserai les URL de mise à jour de Velvet Blues pour nettoyer la base de données si nécessaire.
10. Déboguer
11. La fin

Fondamentalement, je garde le client loin de mes affaires autant que possible jusqu'à ce que nous remettions le site.

Le code se déplace dans un sens - du local à la mise en scène ou à la production. Il ne bouge jamais dans l'autre sens. Cela élimine certaines de vos étapes et me donne une certaine tranquillité d'esprit. Je ne veux pas être blâmé pour le bricolage du client dans mon code et je ne veux pas importer de fichier piraté, ce qui est une possibilité non nulle.

Et la base de données ne se déplace qu'une seule fois, voire pas du tout, ce qui réduit considérablement le problème. Je suppose donc que je gère le problème du «déplacement de la base de données» en réduisant ou en supprimant la nécessité de déplacer la base de données. Il réduit également les problèmes de corruption de base de données qui peuvent survenir et réduit les chances d'importer un hack.

Certes, je dois configurer le site de production - permaliens, menus, etc. - mais cela me force à travailler sur le site de production, donc je le considère comme une sorte de débogage. Cela m'aide à confirmer que les choses fonctionnent sur le site de production comme elles le devraient.

https://github.com/nathanielks/Wordpress-Capistrano-Deploy

Je n'ai pas essayé cela moi-même (encore), mais il prétend tout déployer - DB inclus.

Il y a aussi un tutoriel pour l'accompagner: Tutorial part 1 | partie 2

Jetez un oeil à la pile du substratum rocheux . Il utilise composer pour gérer la version de Wordpress et des plugins tiers, et comprend également capistrano pour les déploiements, et vagrant / ansible pour configurer les serveurs, y compris les serveurs virtuels locaux pour le développement.

J'ai récemment fait beaucoup de tests à ce sujet et voici le flux de travail que j'utilise, qui fait à peu près ce que vous demandez:

• J'utilise wp-cli pour gérer le noyau wordpress et mettre à jour wordpress.
• J'utilise composer avec http://wpackagist.org pour gérer les dépendances des plugins et des thèmes.
• J'utilise git et je place les fichiers wp de base dans le .gitignore. Donc, la plupart du temps, les fichiers de thème wp-config.php et enfant sont dans git.

Je ne suis pas familier avec les outils de migration db mais serait un excellent ajout à ce flux de travail.

Voici tous les détails sur le flux de travail http://geekpad.ca/blog/post/maintainble-portable-wordpress-using-composer-wp-cli

Concernant la base de données "clonage", j'utilise WP Migrate DB Pro: http://deliciousbrains.com/wp-migrate-db-pro/

C'est un service payant, mais ne coûte pas cher et vous permet facilement de tirer ou de pousser votre base de données de votre développeur vers votre serveur en direct et vice versa. Il modifie les URL et tout ce qui doit être modifié en cours de route.