web-dev-qa-db-fra.com

Workflow WordPress et Git

Je sais que cette question a été posée mille fois, mais j'essaie vraiment de comprendre comment tirer le meilleur parti de Git lorsque je travaille 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.

- Contrôle de version 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.

  • Installer WordPress localement
  • Développer le thème
  • Exporter des bases de données WordPress à partir d'un serveur local
  • Importer une base de données WordPress sur un serveur distant
  • Télécharger des fichiers WordPress et le thème via FTP
  • Le client apporte des modifications
  • Téléchargez les fichiers et thèmes WordPress via FTP et exportez les bases de données WordPress depuis un serveur distant
  • Remplacer les fichiers localement
  • Modifie le développement
  • Re-upload via FTP, exportation et importation de la base de données sur un serveur distant

Je me rends compte que Git peut rationaliser ce processus. Il semble que la meilleure façon de procéder consiste à disposer d'un fichier .gitignore qui ignore certains répertoires qu'il n'est pas nécessaire de suivre, ainsi que d'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 (posts/pages/plugins). Dois-je toujours exporter à partir de la base de données distante et l'importer sur mon serveur local?

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

Aussi, j'aimerais probablement utiliser Bitbucket car les pensions privées avec eux sont gratuites, contrairement à GitHub.

Toute aide serait appréciée.

Merci d'avance!

deploymentgit
23
realph

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

"Savez-vous si le script de remplacement de l'URL de base de données 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 raison principale pour laquelle j'ai développé la version gratuite du plugin en 2009. :)

Malheureusement, je n'ai que 41 ans de réputation, je ne pouvais donc pas répondre au commentaire de @ Ennui. Désolé.

6
bradt

Je suis à la limite de voter pour clore ceci comme "non constructif", car cela semble être le genre de chose qui suscitera un débat et une opinion plutôt que des réponses. Mais...

Ce n’est pas ce à quoi ressemble mon flux de travail et cela rend mon approche (et ma réponse) différente de la plupart des autres réponses à ce jour.

  1. Installer WordPress localement
    1. Ceci est cloné à partir d'un dépôt local nu Git contenant la dernière version stable.
    2. Je conserve également une copie locale de la dernière version de quelques plugins que j'installe presque toujours.
  2. Construisez le thème et les plugins nécessaires
  3. Télécharger sur un serveur de transfert intermédiaire public
    1. Le client dispose d'un accès mais ne peut pas modifier le code et indique 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 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 des commentaires de notre personnel et du client.
  5. Transférer les modifications
  6. Répéter autant que 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) allons nettoyer la base de données sur le serveur de transfert et télécharger le contenu.
  8. Déployez en téléchargeant le code local sur le site de production.
  9. Si nous avons créé du contenu, celui-ci est exporté du site intermédiaire via l'outil d'exportation Vanilla et importé dans le site de production.
    1. C’est le seul moment où je dois déplacer la base de données, et cela se fait avec des outils assez standard. Je vais utiliser Velvet Blues Update URLs pour nettoyer la base de données si nécessaire.
  10. Déboguer
  11. La fin

En gros, je garde le client le plus loin possible de mes affaires jusqu'à ce que nous cédions 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 démarches et me donne une tranquillité d'esprit. Je ne veux pas être blâmé pour le bricolage du client dans mon code et je ne veux pas importer un fichier piraté, ce qui est une possibilité non nulle.

Et la base de données ne se déplace qu'une 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. Cela réduit également les problèmes de corruption de base de données qui peuvent survenir et réduit les risques d'importation d'un piratage.

Certes, je dois configurer le site de production, permaliens, menus, etc., mais cela me force à travailler sur le site de production, ce qui est pour moi une sorte de débogage. Cela m'aide à confirmer que les choses fonctionnent comme il se doit sur le site de production.

4
s_ha_dum

J'ai récemment effectué de nombreux 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 de plugins et de thèmes.
  • J'utilise git et met les fichiers wp de base dans le .gitignore. Ainsi, la plupart des fichiers de thème enfant et wp-config.php sont dans git.

Je ne connais pas bien les outils de migration de la base de données, mais ce serait un excellent ajout à ce flux de travail.

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

2
Patrick Forget

Jetez un coup d'œil à la pile de substrat rocheux Il utilise composer pour gérer la version de Wordpress et des plugins tiers, et inclut également capistrano pour les déploiements et vagrant/ansible pour la configuration de serveurs, y compris des serveurs virtuels locaux pour le développement.

2
rjmunro

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

Je ne l'ai pas encore essayé moi-même, mais il prétend tout déployer, y compris la base de données.

Il y a aussi un tutoriel qui va avec: Tutorial part 1 | partie 2

2
Pat J

En ce qui concerne 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 qui ne coûte pas cher et qui vous permet facilement d'extraire ou de pousser votre base de données de votre développeur vers votre serveur réel et inversement. Cela change les URL et tout ce qui doit être changé en cours de route.

1
deadlyhifi