Déployer son site WordPress avec Git

Le 11/07/2013

Dans WordPress

Aujourd’hui sur le Blog du Webdesign, découvrez comment mettre votre site Wordpress en production simplement grâce à Git.

Un des problèmes que je vois à travailler avec WordPress est qu’il n’est pas simple de travailler avec Git. Là où la plupart des applications web en python, nodejs ou ruby se déploierons très simplement avec des outils comme Capistrano, la solution de préférence pour WordPress sera le FTP.

Pourquoi préférer un déploiement par Git à un déploiement par FTP

Pour ceux qui ne connaissent pas Git, allez lire avant toutes choses cet article : Git : Présentation d’un Programme de Versioning Pratique.

Là où avec Git il suffit d’une simple ligne pour passer en production (git push origin production), le faire par FTP impliquera de glisser déposer les fichiers modifiés dans les bons dossiers. Avec git, le risque d’erreur est très réduit, avec FTP, nous pouvons très bien oublier un fichier, ou faire une erreur de manipulation dans notre glisser déposer.

De plus, en cas d’un bug important dans la nouvelle version, Git permet de très vite annuler un changement, ce qui est pratiquement impossible dans un déploiement par FTP.

Enfin, et ce point est crucial pour toute équipe de plus de deux personnes, il est possible avec Git de travailler sur les mêmes fichiers sans pour autant que l’un des membres de l’équipe perde son travail lors du passage en production.

Toutes ces difficultés de productions (passage en prod et travail en équipe) font que la plupart du temps, l’édition de site WordPress se fait « à la cowboy » directement sur le FTP du site en production, sans passer par une pré-prod. Il faut donc mettre le site « en maintenance » plus souvent qu’à son tour, ce qui est vraiment dommageable.

Quels sont les éléments d’un site WordPress managé avec Git

  • Un serveur web local, ainsi qu’une base de données. Cela permettra d’avoir sa version du Wordpress pour faire ses tests, créer des fonctionnalités, installer des plugins, ou mettre à niveau. Certaines personnes conseillent de ne manager que le thème du WordPress, mais dans ce cas, nous passons à coté de toutes les installations de plugins, les traductions et les changements dans le wp-config.php.
  • Un répo Git sur un serveur, ou bien sur Github, pour partager son code entre tous ses collaborateurs. Ce dépôt peut être « bare », c’est à dire nue, sans que le code du Wordpress soit présent dans le dossier. Il n’est présent que comme sauvegarde, et pour synchroniser le code de toute l’équipe.
  • Une pré-prod sur le serveur, pour montrer vos changements au client, et les tester avec la base de données de production (uniquement si besoin, pour ce point)
  • Le site en production, le seul que vos visiteurs verront.

Une fois que vous avez tout ça, il ne vous reste plus, pour déployer le site, que pousser votre code sur le serveur. Bien réglé, votre dépôt mettra à jour la préproduction avec la branche development, et la production avec la branche master. Votre passage en ligne ressemblera donc à "git push origin production" , ce qui est bien moins générateur de stress que d’éditer sur le FTP et croiser les doigts pour que ça marche.

Mise en place du Wordpress et du dépot Git

Pour commencer, preparons notre WordPress.

Installez WordPress en local sur votre serveur de développement (si vous n’en avez pas, songez à http://www.wampserver.com/ ou http://www.mamp.info/en/index.html. Si vous êtes sur Linux, installez simplement apache, php et mySQL), et initialisez votre dépôt Git à la racine du WordPress. Si vous ne savez pas initialiser un dépôt, je vous conseille de commencer par le début.

Une fois ceci fait, ouvrez le fichier caché « .gitignore » . Ce fichier permet de définir une liste de fichiers qui ne seront pas pris en compte par git. Ajoutez-y les listes suivantes :

wp-content/uploads/
wp-content/blogs.dir/
wp-content/upgrade/
wp-content/backup-db/
wp-content/advanced-cache.php
wp-content/wp-cache-config.php
sitemap.xml
sitemap.xml.gz
*.log
wp-content/cache/
wp-content/backups/
.DS_Store

Tous ces fichiers n’ont aucune utilité à être copié en développement. Évidemment, si votre éditeur laisse des fichiers de cache derrière lui, n’hésitez pas à les ajouter à la liste, de même pour les fichiers .nfo si votre Windows en laisse dans les dossiers.

2e étape, le dépôt git et les dossiers de dev et de prod

J’ai déjà traité cette étape dans un tutoriel GIT précédent. Je vous conseille donc d’aller y jeter un oeil avant de continuer.

La seule petite différence est que si vous optez pour deux environnements, prod et dev, il faudra évidemment créer deux dossiers, et penser à check out la bonne branche au bon endroit :

#!/bin/sh

GIT_WORK_TREE=/var/www/monsite.fr git checkout -f master

GIT_WORK_TREE=/var/www/dev.monsite.fr git checkout -f development

Et voilà, nous y sommes, la mise en place du projet est faite.

Octocat wordpress

Pour aller plus loin

Avec tout ça, notre mise en ligne se trouve déjà bien simplifiée, mais il serait possible de faire encore mieux, en mettant en ligne (par exemple) un outil qui prendrait des screens de chaque page lors du passage en pré-prod, et qui comparaîterait ces screens a la dernière version valide (ne riez pas, cet outil existe). De cette façon, il ne serait plus nécessaire de tester toutes les pages a la main, nous pourrions avoir directement un affichage des différences.