web-dev-qa-db-fra.com

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

Je développe actuellement mon WordPress localement, confiant mon code à GitHub avec Git, puis à SSHing sur mon serveur et effectuant un "tirage de 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 connais 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?

deploymentgitgithub
66
Matt

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 fichier .gitignore.
  • 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 fichier .gitignore pour éviter que vos paramètres de développement wordpress ne remplacent vos paramètres de production.
  • Évitez de mettre à jour les plug-ins 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 effectuez un Push/checkout, au pire, vous aurez des conflits. Effectuez vos mises à jour à l'aide de l'interface d'administration de votre système de développement, commit, Push et checkout en production.

  • Pensez à ajouter un hook git post-receive pour extraire automatiquement vos mises à jour dans le répertoire utilisé 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 de 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
59
James Hebden

Je recommanderais vivement de configurer Capistrano. C’est un peu fastidieux la première fois, mais vous pouvez 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/

22
anu

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 voici 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 utilise 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).

9
Matthew Boynes

Je sais que cette question est un peu plus ancienne, mais comme je n’ai pas vu cette réponse ici, je voudrais 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 avec 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:

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

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

  1. mettre le site sur le live-host sous git,
  2. créez 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 actif (dans les codes ci-dessus appelés prime ).

En tant que paramètres spécifiques de Wordpress dans le référentiel, j'ai ce .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 revoir le code before 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 placer des fichiers et des sous-répertoires (par exemple, pour votre dépôt Git simple)

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 répertoire .git de l'accès Web. Voici un exemple de code .htaccess qui fait même que Wordpress est placé 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 ne se trouve pas dans le répertoire public n'est pas en ligne. Dans le répertoire public peut être le wordpress codebase, par exemple, pour le .htaccess il vous faut alors:

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

Cela empêche l'accès direct à public . Une partie de ce .htaccess - foo que vous pouvez trouver est décrite ici: 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 ce soit pour ce que je les 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 dépôt git. Aussi, pour mes commandes de sauvegarde, je ne serais peut-être pas parfaitement d'accord, mais celles-ci fonctionnent 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 fonctionner sur un système spécifique, de sorte que vous ne les avez normalement pas dans l'application (par exemple, une application peut disparaître mais vous besoin pour qu'ils continuent à fonctionner).

Activé pour le travail d'équipe

Un autre avantage de Nice 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.

5
hakre