WordPress et Git Workflow

23

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!

realph
la source
Comment c'était? L'avez-vous compris? Avoir les mêmes problèmes ici.
qwerty
3
Pourriez-vous concentrer un peu votre question? Vous posez des questions sur git, mais passez ensuite aux bases de données et git n'est pas un outil pour les traiter essentiellement.
Rarst
4
Je pense que votre question est valable. J'ai le même flux de travail et en parlant à d'autres développeurs, j'ai remarqué qu'ils ont également le même flux de travail. Mais cela prend vraiment beaucoup de temps et ouvre beaucoup de place à l'erreur. Je serais également intéressé par une meilleure solution.
gdaniel

Réponses:

6

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é.

Bradt
la source
1
Got 50 now :) Great plugin man.
Andrew Bartel
4

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.

s_ha_dum
la source
1
11. La fin - vous n'avez jamais eu à maintenir / patcher / améliorer un site WordPress?
Simon East
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.

rjmunro
la source
2

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

Patrick Forget
la source
1

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.

deadlyhifi
la source
1
Savez-vous si le script de remplacement d'url db qu'il exécute prend en compte les chaînes sérialisées? Une simple requête de mise à jour pour remplacer l'URL est mauvaise car elle casse toute chaîne sérialisée avec une URL (sauf si la nouvelle URL a le même nombre de caractères que l'ancienne URL, ce qui est pour le moins rare). Cela casse les widgets de texte et de nombreux plugins entre autres. J'utilise ce script en ce moment mais je serais intéressé par ce plugin s'il fait la même chose.
Ennui
Je viens d'envoyer un e-mail au développeur pour qu'il vienne répondre à cette question. Je n'en ai pas encore eu besoin.
deadlyhifi
1
J'utilise ce plugin pour tous mes besoins de migration et je n'ai pas encore vu de problème avec les chaînes sérialisées et le remplacement de l'url. Tous les champs personnalisés sont transférés sans problème. Gardez à l'esprit qu'il remplace TOUT par défaut. Cela inclut les utilisateurs / mots de passe / etc ...
hereswhatidid