Utiliser Git avec son site Web (et son stagiaire)

Le 21 juin 2012 — par

Comme la majeure partie des boîtes Web qui liront cela n’auront pas de salariés mais une trentaine de stagiaires à leur actif, j’ai décidé de les aider en apprenant à configurer correctement Git pour travailler efficacement avec leurs esclaves, sans qu’ils ne puissent toucher au code en production. Faut pas déconner.

Tout d’abord, si vous ne connaissez pas (encore) Git, vous trouverez un excellent tutoriel sur Git Immersion. Toutes les bases sont abordées, mais pour faire simple, utiliser Git vous permet d’organiser vos mises à jour. Une approche utilisée depuis longtemps pour le logiciel pur, mais qui a mis du temps à s’imposer pour le Web.

Mes branches

Admettons que vous avez un dépôt (repository) Git pour votre projet Web. Il lui faut, en théorie, au minimum deux branches pour que Git serve à quelque chose :

  • master pour votre code en production, celui que voit vos utilisateurs
  • develop pour le code de la prochaine mise à jour de votre site, celui édité quotidiennement.

Configurer gitolite

Git permet par défaut d’agir comme un serveur origin où chacun peut récupérer les sources du projet. Pour agir finement dans les droits nous aurons besoin de gitolite, une surcouche qui s’installe très simplement sur n’importe quel serveur.

J’y mets dessus ma clé SSH, appelée maxime, et celle de mon stagiaire, et je crée mon dépôt Git avec les deux branches susmentionnées.

Mon fichier de configuration, gitolite.conf, est le suivant :

Cette configuration est la seule partie un peu compliquée, car l’ordre des priorités n’est pas clair sur la documentation. Pour faire simple, je donne d’abord accès en lecture et écriture à tout le monde, puis en lecture seule à mon stagiaire, pour qu’ensuite il puisse avoir ce droit de lecture seule sur tous les noms de fichiers de la branche master mais quand même de l’écriture sur tous les fichiers de develop. Respirez maintenant.

Grâce à cette configuration, votre stagiaire va pouvoir git pull le dépôt Git, voir la branche master en développement, et écrire sur la branche develop pour faire ses mises à jour.

Configuration des dépôts Git

Un des avantages de Git parmi d’autres est qu’il peut appeler différents scripts en fonction de vos actions (répertoire .git/hooks). Par exemple, vous pouvez modifier le script post-commit pour forcer un push à votre stagiaire après chaque commit :

Avant de vous enflammer, je rappelle que ce n’est qu’un exemple, un commit ne justifie en général pas en lui-même un push sur le serveur d’origine.

Puisqu’à la base nous parlions de développer un site Web avec Git, utilisons ce système de hooks du côté du serveur d’origine, pour avoir toujours notre code à jour sans avoir à git pull manuellement. Voici le code à mettre dans post-receive, qui se déclenche à chaque push reçu :

En résumé, si la mise à jour est reçue sur la branche master, on fait un git pull dans le répertoire de production, en faisant attention de bien garder les droits de www-data. Si la mise à jour est reçue sur une autre branche, on fait la mise à jour de pré-production.

Dans mon cas, je fais exécuter un fichier preprod.sh qui ressemble au code suivant :

Ce script permet de git pull le répertoire en paramètre, et de redémarrer le serveur memcache (souvent utile en pré-production, où des clés de test peuvent interférer avec le bon déroulement des essais).

Conclusion

Voilà comment on peut très simplement donner accès à des fichiers et à une version de travail sans pour autant compromettre toute l’intégrité de son code en production. À vous ensuite de vérifier chaque commit avant de pousser les mises à jour de develop sur la branche master.

Si vous souhaitez explorer d’autres modèles de branchage Git, voici un modèle plus poussé chez nvie, et une autre approche avec un hub central chez Joe Maller. Prenez un peu de chaque côté en fonction de vos besoins.

S'abonner au flux RSS du blog
Recevoir les nouveaux articles par e-mail :