🍪🪝 Utiliser les hooks Git pour automatiser des tâches redondantes

juin 05, 2024

Aujourd'hui, Victor, dev back chez Capsens va présenter un outil qu'il a codé tout spécialement pour notre équipe et qui nous fait gagner un temps monstrueux : Des git hooks pour faire appliquer notre norme Ruby.

Ce qui l'a poussé à le faire ? Des retours de style trop redondants et trop fréquents lors des relectures de pull requests.

Chez Capsens, nous avons une norme. Cette norme est une couche supplémentaire aux bonnes pratiques "universelles" Ruby, que nous améliorons en continue. Chaque personne de l'équipe tech peut faire des propositions d'ajout de règles à notre norme puis, une fois par mois on se réuni pour débattre des propositions et décider de les ajouter ou non. Elle nous permet de respecter une certaine harmonie dans le code de nos différentes plateformes et de tous se mettre d'accord (oui c'est important dans une agence web). Nous sommes beaucoup trop nombreux pour que chacun puisse coder à sa sauce, nous avons besoin de ce cadre. Alors, notre priorité est de faire respecter cette norme. C'est pourquoi, pour alléger le travail des relecteurs et des dev, Victor a créé des hooks qui vont vérifier, alerter et corriger les éléments qui ne respectent pas notre norme, et ce, avant chaque commit.

Au programme aujourd’hui :

Utiliser les hooks Git pour automatiser des tâches redondantes par Victor

Temps de lecture : 5 minutes

Hello les petits Biscuits !

Bienvenue sur la 22ème édition de Ruby Biscuit.
Vous êtes maintenant 487 abonnés 🥳

Comme je vous l’annonçait hier, Ruby Biscuit développe son service de recrutement !
RDV sur recrutement.rubybiscuit.fr 🍪

Annonce du mois :
Le Wagon Paris organise un salon du recrutement qui aura lieu le vendredi 21 juin. Si vous êtes recruteur, à la recherche de profils tech (dev junior, data et product) pour agrandir vos équipes vous pouvez vous y inscrire ici !

Bonne lecture.

Utiliser les hooks Git pour automatiser des tâches redondantes

Lorsqu'on travaille dans une équipe de dev, que cette équipe grandit et que les projets se multiplient, le maintien d'un code propre et conforme aux standards devient vite un casse-tête. Il est essentiel de standardiser le code et crucial de le faire sans alourdir le processus de développement.

Aujourd'hui notre norme est écrite sur des Slites soigneusement découpées et illustrées par des exemples. Malgré cela, les nombreux retours de mise en pratique de cette norme sur les pull requests montraient qu'on manquait d'une solution plus intégrée.

Les hooks Git se sont révélés être une solution idéale.

Faisons une parenthèse théorique pour que je vous explique de quoi on parle exactement.

Qu'est ce que les git hooks

Les hooks git sont des scripts qui s'exécutent automatiquement avant ou après certaines actions git.

Les plus communs sont les suivant :

Pre-commit : Ce hook s'active juste avant qu'un commit soit finalisé. Il est idéal pour effectuer des vérifications de dernière minute, comme l'exécution des tests unitaires ou la vérification du style de code. Si le script renvoie une erreur, le commit est annulé, ce qui aide à maintenir la base de code propre et fonctionnelle.
Post-commit : Exécuté immédiatement après qu'un commit a été effectué, ce hook est souvent utilisé pour des notifications ou des logs qui informent d'autres services ou des membres de l'équipe que de nouvelles modifications ont été enregistrées.
Pre-push : Avant que les modifications soient envoyées à un serveur distant, le hook pre-push permet de vérifier l'intégrité du code et des tests. Cela garantit que seul le code vérifié et testé est partagé avec d'autres, réduisant les risques de régression.
Post-merge : Après une fusion réussie, ce hook peut être utilisé pour restaurer les dépendances ou nettoyer le répertoire de travail, s'assurant que l'environnement de développement reste sain et opérationnel après l'intégration de nouvelles modifications.

Les hooks sont stockés dans le dossier .git/hooks d'un repo git et ne sont pas versionnés.

Mise en pratique dans notre équipe

La solution que j'ai choisie pour notre problématique a été de créer un hook git qui se déclenche au moment du commit (pre-commit) pour vérifier le code et bloquer le commit si le code ne respecte pas notre norme.

Il y avait quand même un souci.

Comme les hooks ne sont pas versionnés alors que la norme est changeante, comment faire en sorte que tous les devs aient dans leurs repos le bon hook sans avoir à le copier-coller et le mettre à jour à chaque changement de norme ?

La solution que j'ai trouvé à été de créer une lib de hooks git facile à installer et mettre à jour sous la forme d'un CLI (interface de ligne de commande).

Un clone du repo, un script d'install à lancer et on peut ajouter nos hooks à un repo avec un simple capsens-git-hook install.

Un coup de capsens-git-hook upgrade et tous les hooks installés dans les repos sont mis à jour.

Un coup de capsens-git-hook autofix et les fichiers modifiés sont corrigés automatiquement selon la norme.

J'en ai aussi profité pour ajouter deux autres hooks

- prepare-commit-msg Préfixe le commit avec le numéro de la branche (correspondant à celui de la carte Trello liée)

- pre-push Vérifie les conflits entre la branche actuelle et la branche staging et propose de créer une branche de conflit.

Ça a été plutôt fun de travailler sur ce projet, ça m'a permis d'apprendre plein de chose en shell et parfois aussi de bien se prendre la tête ! 🤓

Le bug le plus intéressant que j'ai eu à résoudre était celui de la commande upgrade. La commande fait un git pull sur le repo de la lib et lance le script d'install. Tout semblait fonctionner correctement jusqu'à ce que je modifie le fichier contenant le script d'upgrade. Il fallait faire en sorte que le fichier qui lance l'upgrade puisse être mis à jour tout en continuant de s'exécuter correctement, un peu comme si on voulait changer les cordes d'une guitare et jouer en même temps.

Il fallait donc lancer le script d'installation dans un sous shell ( ... ). Ça veut dire que même si on met à jour le script d'upgrade, le sous-shell garde la version initiale le temps que tout se termine. Puis l'exécuter en background en ajoutant simplement & après la commande. Comme ça, même si on met à jour le script pendant qu'il s'exécute, pas de crash, il finit son job correctement.

Aujourd'hui, je suis fier de ce projet et du temps qu'il fait gagner à toute l'équipe mais aussi des débats qu'il a pu lancer ou relancer sur la norme de code au sein de Capsens.

J'espère que ça vous inspirera pour fluidifier des process de developpement dans votre boite et si c'est le cas, je vous conseille de commencer par lire ça : https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks. 😉

— Victor