Git / GitHub est-il une bonne solution de déploiement WordPress?

Je développe actuellement mon WordPress localement, en validant mon code dans GitHub avec Git, puis en SSH sur mon serveur et en effectuant un "tirage git" pour mettre à jour mon code. Est-ce une bonne option pour le déploiement de code sur un site WordPress (dans ce cas, j’ai évidemment un accès de niveau racine à mon serveur). Je sais des choses comme Capistrano, mais est-ce que c’est excessif pour un déploiement sur un site WordPress? Comment puis-je tirer le meilleur parti de Git / GitHub dans ce cas?

J'utilise git pour cela et trouve que ça marche vraiment bien. Quelques suggestions:

• Ajoutez votre répertoire de téléchargement (wp-content / uploads) à votre .gitignorefichier.
• Exécutez un serveur Web et un serveur de base de données sur votre système de développement afin de pouvoir tester les modifications localement avant de les transférer en production.
• Conservez les paramètres de connexion de votre base de données cohérents entre dev et prod ou ajoutez wp-config.php à votre .gitignorefichier pour éviter que vos paramètres de développement wordpress ne remplacent vos paramètres de production.
• Évitez de mettre à jour les plugins sur votre système de production à l'aide de l'interface d'administration de Wordpress - au mieux, votre copie git écrasera tous les plugins que vous mettez à jour dès que vous poussez / vérifiez, vous aurez au pire des conflits. Effectuez vos mises à jour à l'aide de l'interface d'administration de votre système de développement, validez, envoyez et vérifiez en production.

• Envisagez d'ajouter un point d'ancrage git post-receivepour vérifier automatiquement vos mises à jour dans le répertoire que vous utilisez pour publier wordpress via votre serveur Web (par exemple /var/www). Cela vous permet uniquement d'extraire les fichiers eux-mêmes, en évitant que les métadonnées git se retrouvent dans la racine du document de votre serveur Web. Cela signifie également que vous pouvez ajouter toute modification d'autorisation dans le hook post-réception afin que vos autorisations restent cohérentes à chaque fois. Un exemple est inclus ci-dessous:

  #!/bin/sh
  unset GIT_INDEX_FILE
  # the directory your web server serves wordpress from 
  export GIT_WORK_TREE=/var/www/example.com/
  # the local directory where your remote git repository sites
  export GIT_DIR=/home/git/repos/example.com.git/
  # below user is for debain - you want the user and group your webserver uses
  sudo git checkout -f
  sudo chown -R www-data:www-data $GIT_WORK_TREE
  sudo chmod -R 755 $GIT_WORK_TREE
  sudo chmod 600 $GIT_WORK_TREE/wp-config.php
  sudo chmod -R 775 $GIT_WORK_TREE/wp-content
  

Je recommanderais vivement de configurer Capistrano. C’est un peu fastidieux la première fois, mais vous pourrez ensuite l’utiliser facilement pour de nouvelles configurations.

Les principaux avantages sont

• être en mesure de déployer à partir de votre bureau. Cela peut ne pas sembler beaucoup, mais ssh-ing sur votre serveur distant, et tirer un git est toujours une douleur dans le cul.
• retour facile à une version précédente si vous en avez besoin
• capable de faire des choses intéressantes comme le déploiement de la configuration dans des environnements de transfert / de production.

J'ajoute un ensemble de scripts capistrano pour vous montrer comment je règle les choses.

Capfile

require 'railsless-deploy'
load 'config/deploy'`

deploy.rb

set :stages, %w(production staging local)
set :default_stage, "staging"
require 'capistrano/ext/multistage'

set :application, "" # your application name - used to set directory name

set :scm, :git
set :repository, "" # use the ssh repo access line you get from the provider eg [email protected]:name/repo.git
set :deploy_to, "/var/www/#{application}" #this is the root site folder on the remote server
set :deploy_via, :remote_cache # get directly from repo
set :copy_exclude, [".git", ".DS_Store", ".gitignore", ".gitmodules", "wp-config.php"]

# makes capistrano ask for sudo password or other remote inputs
default_run_options[:pty] = true

namespace :tasks do
    task :fix_links  do
        run "ln -nfs #{shared_path}/uploads #{release_path}/wp-content/uploads"
        run "ln -nfs #{shared_path}/wp-config.php #{release_path}/wp-config.php"
      run "ln -nfs #{shared_path}/blogs.dir #{release_path}/wp-content/blogs.dir"
      run "ln -nfs #{shared_path}/.htaccess #{release_path}/.htaccess"
      run "sudo chown -R www-data.www-data #{release_path}/"
    end
end

after "deploy", "tasks:fix_links"

et enfin, un exemple de fichier d’environnement (si vous utilisez le gem à plusieurs étages, vous pouvez en avoir un pour chaque étape de votre environnement, par exemple local, transfert, production)

config / local.rb

server "", :app  #hostname
set :branch, 'develop' #choose branch to deploy
set :use_sudo, false #don't use sudo

set :deploy_to, "/var/www/#{application}" #overwrite default path to deploy to

Ces fichiers risquent de ne pas fonctionner sans modifications, et vous aurez besoin de connaissances de base en Capistrano, mais espérons pouvoir aider certaines personnes.

C’était le premier tutoriel que j’ai utilisé et qui m’ait donné à démarrer avec Capistrano et WordPress: http://theme.fm/2011/fr/tutorial-deploying-wordpress-with-capistrano-2082/

J'ai en fait fait une présentation WordCamp sur ce sujet. Plutôt que de me répéter, voici un extrait vidéo et un script de déploiement très simple pour accompagner ce que j'ai discuté.

En bref, j'utilise GitHub pour héberger le référentiel et un webhook pour déployer les modifications basées sur la référence git. Cela vous permet d'utiliser le modèle de branchement git de Vincent Driessen et vous permet d'avoir un nombre illimité de têtes Web, de serveurs de transfert, de serveurs de test, etc., le tout avec un déploiement automatisé. Je couvre également le maintien de wp-config.php sous contrôle de version tout en maintenant des versions de développement / production séparées (en renommant les fichiers et en créant des liens symboliques).

Je sais que cette question est un peu plus ancienne, mais comme je ne l’ai pas vu ici, j'aimerais partager ce que je fais normalement pour les installations et les déploiements basés sur git sur un seul site et cela fonctionne très bien, même si vous travaillez à partir de plusieurs. périphériques, emplacements et avec plusieurs développeurs (tous ayant leur propre dépôt local dans lequel ils opèrent, comme c'est commun pour git).

Je peux suggérer chaleureusement la configuration suivante:

• Un flux de travail Git centré sur le Web (par Joe Maller; nov. 2008)

Il est également décrit dans (si vous avez besoin d'une deuxième ressource pour bien comprendre):

• Utiliser Git pour le déploiement (par Dan Barber; avril 2011)

Cela fonctionne essentiellement (avec au moins trois pensions) en:

1. mettre le site web sur l'hôte live sous git,
2. créer un nouveau référentiel Git nu sur l'hôte actif.
3. Et branchez ensuite du référentiel nu à votre (vos) dépôt (s) git de développement local.

Lorsque le travail est terminé, vous appuyez sur le dépôt nu distant à partir duquel vous avez cloné. Le référentiel nu a des points d'ancrage pour la synchronisation avec le référentiel en direct (dans les codes ci-dessus appelés prime ).

En tant que paramètres spécifiques de Wordpress dans le référentiel, j'ai ceci .gitignore:

# uploads are data, excluded from source tree
wp-content/uploads/

Le reste incl. le plugin et la configuration du thème que je conserve sous contrôle de version / configuration. Cela me permet de suivre facilement les modifications et de réviser le code avant de l’ utiliser en direct. Je peux aussi plus facilement fusionner contre des arbres distants avec mes propres modifications. Cela est particulièrement utile contre le noyau Wordpress disponible sur Github .

Cela fonctionne assez bien pour la plupart de mes besoins Wordpress. Le repo nu vous empêche de pousser des modifications contradictoires. Il se synchronise également sur une copie distante avant de mettre à jour le site actif. Cela signifie que la mise à jour du site en direct est normalement assez rapide. Grâce aux points d'ancrage, vous pouvez même appeler les points d'ancrage de mise à jour Wordpress ultérieurement si vous le souhaitez.

Si je n'ai pas expérimenté dans quelle mesure cela peut être amélioré avec les hooks Github, mais normalement je n'en ai pas besoin car le code est sous contrôle de version local, pas Github.

Pour configurer un tel système pour la première fois, prenez le temps d'évaluer si vous disposez de tous les outils disponibles sur votre hôte distant:

• Accès SSH
• GIT
• Un répertoire privé dans lequel vous pouvez mettre des fichiers et des sous-répertoires (par exemple pour votre dépôt Git nu)

Le temps d'installation pour la première fois devrait être possible dans un délai de deux heures, incl. tout l'environnement et vous publiez d'abord push.

En fonction de votre hôte, vous pouvez également vouloir protéger le .gitrépertoire de l'accès Web. Voici un exemple de .htaccesscode permettant de conserver Wordpress dans un sous-répertoire, ce qui laisse un espace dans le référentiel non publié en ligne (utile):

Options -Indexes

# fix trailing slash for .git / make it disappear + .gitignore and similar files.
RedirectMatch 404 ^/\.git(.*)$

# mask 403 on .ht* as 404
<Files ~ "^\.ht">
  Order Deny,Allow
  Allow from all
  Satisfy All
  Redirect 404 /
</Files>

RewriteEngine On
RewriteBase /

# map everything into public and set environment var
# to tag the request being valid
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule ^(.*)$ /public/$1 [E=sitealias:set,L]

En bref, tout ce qui n'est pas dans l' annuaire public n'est pas en ligne. À l'intérieur du répertoire public , vous pouvez trouver le wordpress codebase, par exemple .htaccess:

RewriteEngine On
# mask as 404 if directly accessed
RewriteCond %{ENV:REDIRECT_sitealias} !set
RewriteRule .* - [L,R=404]

Cela empêche l'accès direct au public . Une partie de ce fichier .htaccess -foo que vous pouvez trouver est décrite ci-dessous: Les demandes adressées à .htaccess doivent renvoyer 404 au lieu de 403 . Pour les variables d’environnement, vous devez vérifier si cela fonctionne dans votre environnement. Vous devez également décider si vous placez cela sous contrôle de version ou non.

Si vous avez plus de contrôle sur l'hébergement, vous pouvez faire plus de choses ici (et différemment / plus optimisées), les exemples ci-dessus sont destinés aux environnements d'hébergement partagé typiques (qui offrent GIT, certains utilisateurs disent que vous pouvez facilement l'installer vous-même. eh bien, je demande normalement à mes hébergeurs de fournir cela, car je préfère que s’ils s’occupent de ce que je leur paye).

Du côté négatif, cela présente certains des problèmes communs également décrits dans les autres réponses. Une chose dont je ne suis pas fier, mais ce qui fonctionne, c’est de donner à l’hôte de développement une modification de son fichier d’hôte pour que le serveur de base de données pointe sur la copie de développement. Vous pouvez donc conserver une configuration de base de données. Pas vraiment cool esp. à cause des informations d'identification.

Sauvegardes automatiques

Cependant, normalement, je ne me soucie guère de faire cela ici, mais de faire des sauvegardes quotidiennes sur les systèmes distants qui sont incrémentiels et qui sont eux-mêmes stockés dans un autre emplacement distant. C’est simple et peu coûteux et vous permet de restaurer à la fois l’installation Wordpress ainsi que les fichiers téléchargés, la base de données et le référentiel git. Également pour mes commandes de sauvegarde, je ne serais peut-être pas parfaitement d'accord, mais cela fonctionne pour moi:

mysql: mysqldump --host=%s -u %s --password=%s %s| gzip > %s
git  : git gc
       git bundle
files: tar --force-local -czf %s %s

Ce que je suggère ici est que vous gardiez les processus autour de votre installation Wordpress en dehors de Wordpress. Ils doivent être exécutés sur un système spécifique. Par conséquent, ils ne sont normalement pas intégrés à l'application (par exemple, une application peut disparaître mais vous devez les faire continuer).

Activé pour le travail d'équipe

Un autre avantage intéressant est que votre site est déjà activé pour le travail en équipe. Grâce à la mise à nu supplémentaire, vous ne pouvez pas faire grand chose de mal et vous pouvez même partager des branches distantes en dehors d'une branche principale ou en direct avec vos collègues.