Blog

Comment versionner et déployer un CMS avec git

Écrit le 19 01 2017 par Kévin MET _

Introduction

Aujourd’hui on va parler de ma façon de versionner et déployer avec git, WordPress ou tout autre CMS qui se met à jour via son interface web comme Drupal, Magento, Prestashop, etc. Pour commencer il vous faut un dépôt git dans lequel se trouve le dossier contenant la totalité de votre site. Si vous ne savez pas comment mettre en place un dépôt git, j’avais fait un rapide tutoriel à propos de l’utilisation de git et de gitlist, vous pouvez vous en inspirez pour commencer avec git. De plus, pour suivre ce tutoriel il est plus simple d’avoir déjà mis en place un environnement de développement comme je l’ai expliqué dans ce précédent tutoriel sur le dev d’un thème WordPress sur un sous-domaine. Ce n’est pas obligatoire mais cela permet de faire son développement sur le même serveur que la prod sans impacter les utilisateurs. Je suppose que ce genre de chose est également possible sur tous les autres CMS moderne, il faut chercher...

Principes de fonctionnement

Je vais commencer par expliquer un peu comment je fonctionne avant de vous faire mettre les mains dans le cambouis. Déjà il faut savoir que c’est une fois de plus un tuto à mi chemin entre admin et dev car il y a des manips à faire coté serveur et de l’utilisation de git qui se rapproche plus du quotidien d’un développeur. Pour le déploiement de git, je fais appel au hooks de git, le hook post-update et je déploie via rsync en passant par ssh. Pour la gestion de versions, je fais appel à un simple petit script bash utilisant également rsync via ssh que j’utilise depuis mon dépôt local pour rapatrier mes modifications ou les mises à jours du CMS et de ses plugins.

Gestion de versions (à faire sur votre PC local)

Pour commencer on va gérer la gestion de versions. La particularité de ma méthode c’est que j’englobe tout le dossier WordPress (ou autres), ce qui veut dire que lorsque vous mettez à jour un plugin ou le core de WordPress via l’interface web il faut rapatrier ces différences dans votre dépôt git pour les prochains déploiements. Cela permet donc de faire un rollback avant la maj d’un plugin ou de WordPress très facilement grâce à git. Pour l’exemple, on va dire que le dépôt git se nomme mad-rabbit.com.git et qu’on utilise l’user infogerance-serveur-linux (oui, le nom de cet user n'est là que pour le SEO) via ssh sur ce dépôt. On commence donc par cloner le dépôt sur notre machine locale :


git clone ssh://infogerance-serveur-linux@git.mnt-tech.fr:22/home/chemin/vers/depot/mad-rabbit.com.git

Puis on se met dans le dépôt et on y ajoute ce script que l'on nomme rsync.sh (à adapter en fonction de votre serveur et de vos chemins) :


#!/bin/bash
rsync -avz --exclude '.git' --delete -e "ssh" root@web0.mad-rabbit.com:/home/madrabbit/www/ .

Dans mon cas le dossier du site web est sur le serveur web0.mad-rabbit.com dans le dossier /home/madrabbit/www/.

Cela va permettre de récupérer les dernières modifications que l’on a effectué sur le serveur, tout simplement en l’exécutant comme ça :


bash rsync.sh

Cela implique que vous soyez en local sur une machine linux. Peut-être que cela fonctionne sous cygwin (à vérifier mais je ne vois pas pourquoi cela ne fonctionnerait pas). Il est même probable qu’en installant la version de git CLI pour windows vous pouviez installer rsync car il me semble que la version git de windows utilise cygwin… (Également à vérifier par un windowsien car je n’ai pas installé cela depuis très longtemps et cela a pu changer depuis.)

Pour ne pas avoir votre mot de passe à taper vous pouvez utiliser ssh via une paire de clé. Je vous laisse chercher sur internet pour savoir comment mettre en place de genre d’authentification.

Dans l’état vous êtes donc capable de faire des modifications sur le serveur, de lancer le script en local pour les récupérer et ensuite de faire un commit et un push. Dans la suite, nous allons voir comment faire pour que votre push déclenche la mise en prod de votre branche master.

Déploiement (à faire sur vos serveurs)

On commence par créer un dossier temp dans le même dossier qui contient votre dépôt git et faire un premier clone en utilisant l’user que vous utilisez avec git. Dans mon exemple, le dépôt se nomme mad-rabbit.com.git et mon user est toujours infogerance-serveur-linux.

Je commence donc par faire un dossier temp à coté de mon dépôt git :


cd /home/chemin/vers/depot/
mkdir temp

et je fais un clone


git clone mad-rabbit.com.git/ temp/mad-rabbit.com

Cela va créer un premier clone de votre dépôt dans le dossier temp et il faudra changer les droits pour que votre user git puisse le modifier :


chown -R infogerance-serveur-linux: temp/mad-rabbit.com

Pour le déploiement j’utilise ce hook post-update (à adapter à vos serveurs et vos chemins). Dans mon cas, le dépôt est sur un premier serveur et le site est déployé sur un second serveur (web0.mad-rabbit.com) dans le dossier /home/madrabbit/www :


#!/bin/bash

echo "**************** Mise en production ***************"
cd /home/chemin/vers/depot/temp/mad-rabbit.com
unset GIT_DIR
git fetch --all
git clean -dff
git reset --hard origin/master
git pull origin master
sudo /usr/sbin/rsync-to-prod
echo "**************** Mise en production terminée ***************"

Ce script est à mettre dans le fichier post-update qui est dans le dossier hooks de votre dépôt git. Attention, le dépôt qui se trouve sur votre serveur, pas le dépôt local qui se trouve sur votre PC. Il faut penser à rendre ce fichier exécutable par l’utilisateur qui fera le push sur le dépôt. Je ne vais pas détailler son fonctionnement car toutes les options de git sont déjà très bien documentées mais en gros, avant le sudo, le script s’assure que le dossier dans temp reflète la dernière version de la branche master de votre projet et le sudo envoie le dossier sur votre serveur de prod via le script /usr/sbin/rsync-to-prod. Si je résume, à chaque push votre dépôt sera redéployé en prod.

Le contenu du script /usr/sbin/rsync-to-prod est le suivant (une fois de plus à adapter à votre environnement) :


#!/bin/bash
chown -R www-data:www-data /home/adplusplus/temp/$1
find /home/adplusplus/temp/mad-rabbit.com -type f -exec chmod 664 {} \;
find /home/adplusplus/temp/mad-rabbit.com -type d -exec chmod 775 {} \;
rsync -avz --exclude '.git' --delete -e "ssh" /home/chemin/vers/depot/temp/mad-rabbit.com/ root@web0.mad-rabbit.com:/home/madrabbit/www

Une fois de plus, le script doit être adapté à votre situation. Dans mon cas, j'utilise le dossier /home/madrabbit/www sur mon serveur web et j'en profite également pour corriger les droits et changer l'owner et le group du dossier. Dans mon cas l'user est www-data mais cela peut être différent pour vous, pareil pour les droits sur les fichiers. Il faut donc vérifier avant de mettre le script en place.

Attention, pour que le rsync fonctionne bien il faut penser à mettre en place un système d’authentification par clé pour ssh. Pour cette partie, comme indiquez plus haut, je vous laisse chercher sur le net, le tutoriel est déjà assez long comme ça. Il faut également penser à ajouter votre user ou votre group git dans sudo pour qu’il lance le script sans demander de mot de passe. Pour cela on édite le fichier /etc/sudoers en ajoutant ceci :


# Pour un groupe
%group-de-git ALL = NOPASSWD: /usr/sbin/rsync-to-prod

# Pour un user
infogerance-serveur-linux ALL = NOPASSWD: /usr/sbin/rsync-to-prod

Conclusion

Voilà, ce tutoriel est un peu long et compliqué mais cette méthode est vraiment super pratique pour versionner et mettre en prod un projet web qui propose des mises à jours via son interface web comme WordPress, Magento, Drupal, Prestashop, etc. Si vous rencontrez des problèmes, n'hésitez pas à laisser un commentaire en expliquant votre soucis.

♥ Partage sur tes réseaux sociaux ♥
Kévin MET
Kévin MET

Auteur de ce blog et gérant de la société MNT-TECH, je publie sur ce blog lorsque le temps me le permet et lorsqu'un sujet qui me parait intéressant n'a pas encore été abordé en français. Toutes les informations techniques présentes sur cette page peuvent être réutilisées moyennant le fait de citer la source.