Git Workflow avec WordPress - Localhost to Live

Question

J'ai une question basique mais courante sur le flux de travail de WordPress.

Flux de travail actuel

1. Je développe tout localement
2. FTP des fichiers (et du dumping de la base de données) vers le serveur pour montrer au client
3. Effectuer les modifications demandées localement
4. Remonter les fichiers FTP (et le dumping de la base de données) sur le serveur
5. Plus d'éditions locales
6. FTP (et vidage de la base de données) à nouveau disponible
7. Rincer et répéter

C'est devenu un casse-tête monstre. Il doit y avoir un meilleur moyen

Flux de travail Git suspecté

1. La copie locale sera mon "maître
2. Pousser les fichiers quelque part
3. Tirer les fichiers de cet endroit au milieu vers mon serveur live/de test.

Je pense que j'ai une idée de la manière dont il faudrait procéder sur le plan conceptuel, mais je ne sais pas comment il faudrait procéder sur le plan pratique. Devrais-je utiliser un repo privé Github au milieu ? Est-ce qu'il y a un moyen pour mon site Live de "tirer" directement de mon repo local ?

Je vous prie de m'excuser si cela vous semble élémentaire ou déjà dit, mais j'ai eu beau chercher, je n'ai pas trouvé de guide de base "Voici à quoi devrait ressembler votre flux de travail".

Merci beaucoup !

Terry

Answer 1

Il semble que vous n'utilisiez pas du tout le contrôle de version. C'est une bonne idée de commencer. I juste Je suis passé de SVN à Git, et je fais en quelque sorte ce que vous faites à un niveau plus élevé. Commençons par vos objectifs :

1. Obtenir le contrôle de la version
2. Mettre en place une sorte de déploiement web via Git
3. Héberger le contrôle de version à distance

Les gens vous diront que Git n'est pas un outil de déploiement web - ils ont peut-être raison, mais jusqu'à présent cela fonctionne bien pour moi, et j'ai fait quelque chose de similaire. Heureusement pour vous, j'ai pratiqué sur une installation de Wordpress - voici les étapes que j'ai suivies.

1. J'ai tout configuré et installé avec Git en ce qui concerne le client.
2. J'ai téléchargé la dernière version de Wordpress dans une installation vanille.
3. git init l'installation de base sans aucune modification
4. Branchement du master en "dev" et "live"
5. Travailler localement, commiter dans "dev", puis une fois les changements effectués, fusionner dans "live".

Ce que j'ai fini par faire, c'est de créer un fichier gitolite et de l'utiliser comme hôte - ce qui remplace effectivement github dans votre exemple. Je pense que vous connaissez la valeur d'un dépôt distant - je poursuivrais certainement cette voie.

Je vais revenir un instant sur l'étape 2 de mes recommandations. Vous devriez garder la version vanille de Wordpress sur le master afin de pouvoir mettre à jour le core et voir comment il fonctionne avec votre code personnalisé, au lieu de mettre à jour le core sur quelque chose comme une de vos branches et que tout se casse la figure. Cela s'est avéré très pratique pour moi, et c'est quelque chose que je vais définitivement utiliser sur des projets plus importants comme Magento.

Ok, revenons au déploiement. Vous pouvez mettre un client git sur votre serveur web et le faire fonctionner comme suit pull à partir de sa branche dans le flux de travail - mais vous devez tenir compte de certaines considérations particulières en matière de planification. Vos fichiers prod seront très probablement différents de vos fichiers dev à certains endroits, en particulier la configuration (base de données, etc.) - vous voudrez vous assurer que ces fichiers sont dans le répertoire .gitignore pour que vous ne tiriez pas vers le haut dev dans votre prod l'environnement.

J'ai surtout résumé ce que les gens m'ont dit lorsque j'ai commencé à travailler sur ce projet, j'espère que cela vous aidera. Encore une fois, je suis un peu plus loin que vous, donc si quelqu'un a des corrections/optimisations à faire, n'hésitez pas à commenter.

Answer 2

Je commence à mettre en place un tel flux de travail pour Wordpress. Je l'ai déjà mis en place pour quelques autres projets web.

J'utilise l'outil gitolite (https://github.com/sitaramc/gitolite/wiki/) pour gérer les dépôts nus (dépôts sans vérification locale) dans un emplacement central, puis déclencher un crochet de mise à jour dans gitolite lorsqu'une branche est poussée depuis l'emplacement de développement.

Ce crochet se connecte alors au serveur live (ou au compte du client ou autre) avec une clé privée partagée stockée sur le serveur de déploiement, et effectue une extraction git à partir de public_html ou de tout autre emplacement où se trouve votre installation Wordpress.

Cela se fait en utilisant une entrée en lecture seule dans le fichier de configuration de gitolite qui est conf/gitolite.conf dans le référentiel de configuration local. (Gitolite utilise un dépôt git pour gérer ses fichiers de configuration).

repo wp-versions
  RW+ = tmzt
  R = server1
  R = server2

La première est ma clé publique principale, qui est stockée keydir/tmzt.pub dans le même dépôt (même format que .ssh/authorized_keys). Les deux autres sont des serveurs web live qui auront un accès en lecture seule au référentiel. Ajoutez les trois clés à keydir et assurez-vous de faire un commit et un push. Les changements seront automatiquement effectués dans l'installation de gitolite. (Les clés du serveur sont partagées par plusieurs utilisateurs et copiées dans le fichier .ssh/id_rsa de chaque utilisateur, mais cela pourrait être www-data si vous préférez).

RW+ signifie que mon utilisateur principal a les droits de lecture et d'écriture, et qu'il peut mettre à jour les branches sans avance rapide (ce qui est utile pour annuler les modifications sur le serveur).

Answer 3

Je comprends que c'est tellement ennuyeux et fastidieux que beaucoup de développeurs choisissent une méthode professionnelle pour le faire. Cela les aidera non seulement à gagner du temps mais aussi à améliorer la productivité de leur travail. Fondamentalement, il y a deux scénarios principaux dans le flux de travail de développement WordPress GitHub. Le premier consiste à utiliser WordPress et Github dans un environnement réel, et l'autre à travailler dans un environnement local. Dans le cas d'un environnement local, le processus est simple. Tout ce que vous avez à faire est de pousser et de tirer les changements de GitHub vers l'environnement local ou vice versa.

(travailler dans un environnement réel avec plusieurs équipes est assez complexe)

Dans un environnement réel, il faut d'abord pousser les fichiers du site WordPress vers le dépôt GitHub, puis les tirer vers le dossier local.

Ensuite, construire l'environnement de développement sur la machine locale (éditer le code) et pousser du local vers GitHub.

Pour transférer les modifications dans l'environnement réel, il faut d'abord connecter GitHub à l'environnement réel.

Vous pouvez lire ce guide détaillé sur WordPress et GitHub et j'espère que cela vous aidera : https://www.cloudways.com/blog/wordpress-github/