Un git flow structuré pour garder une vision claire du projet
Chez Captain Contrat, nous avons adopté un git flow assez classique. Nous ne réinventons pas la roue, mais nous y avons toutefois apporté quelques ajustements et conventions pour qu’il corresponde à nos besoins et à notre structure en interne.
Cette étape est encapsulée dans notre task flow, qui lui s’étend bien en amont et en aval, et comprend quelques cérémonies scrums telles que le sprint planning et la démo. Il correspond au cycle de vie d’une tâche : la définition de son scope, la spécification des règles qui la composent, son développement, sa validation, sa mise en production.
Le scope du git flow se limite donc à l’utilisation de git et des webhooks de github, mais exclut Zenhub, notre outil scrum. Nous considérons que notre git flow démarre lorsqu’un développeur s’assigne à une tâche et l’entame par la création de sa branche git, et se termine lorsque cette dernière est fusionnée dans la branche principale.
La branche
Nous privilégions les petites Pull Requests et donc de petites branches : plus agréables à relire et moins source d’erreurs d’étourderie. C’est pourquoi nous essayons de diviser le code pour un même ticket en plusieurs branches quand cela est possible. Parfois la séparation se fait d’elle-même : une branche pour le dépôt contenant notre API et une seconde sur notre dépôt client.
Le nom de la branche, s’il suit des conventions, peut s’avérer plus que pratique. Nous avons opté pour le format suivant :
type/id-issue_titre_court
Chez Captain, nous pouvons identifier 3 types de branches :
- La “feature”, qui est un ajout ou une modification de fonctionnalité. Les tests vont de pair, ils sont inclus sur la même branche ;
- La “tech”, qui permet de réduire notre dette technique ;
- Le “fix” ou le “bug”, qui est la correction d’un bug. Nous y traitons également des patchs pour résoudre la cause profonde du problème.
L’identifiant nous permet de retrouver le ticket associé à la branche, et le titre court d’expliciter son scope. Un même ticket peut en effet être fragmenté en plusieurs ajouts de code pour réduire la charge mentale lors des relectures.
Cette convention n’est pas figée dans le marbre. Nous restons à l’écoute de ce qui se fait et nous nous adaptons aux besoins de la team. Auparavant, nous n’avions pas d’identifiant dans le nom de la branche, et le format a évolué lorsque nous avons recruté un développeur qui avait pris cette habitude.
Le commit
Nous ne sommes pas très regardants sur nos commits et ne faisons pas de descriptions détaillées, mais essayons tout de même de privilégier des petits commits avec des titres courts et explicites. En effet, nos branches sont squash and merge, c’est à dire que tous nos commits sont fusionnés en un seul au moment du merge. L’historique git perd donc l’information, mais il est toujours possible de retourner voir la Pull Request qui conserve tout en mémoire. L’ensemble des titres des commits sert alors de résumé des opérations qui ont été effectuées sur la branche supprimée.
Par convention, nous écrivons le nom des commits en anglais.
La Pull Request
La Pull Request peut être ouverte peu importe l’avancée dans le développement.
L’ouvrir assez tôt avec un label “In progress” nous permet de vérifier que le développeur assigné a choisi la meilleure solution à sa portée. La communication reste malgré tout importante et nous avons souvent une phase de discussion avant d’attaquer une tâche.
Cela nous permet également de faire jouer les hooks de Github : CircleCi pour nos tests, CodeClimate pour les alertes de sécurité, nos linters tels que RuboCop ou ESLint et le calcul de notre couverture de test.
Dès que la Pull Request est prête pour une relecture, nous assignons deux reviewers, qui sont généralement les deux autres développeurs qui composent la squad.
La code review
La code review est l’étape de la relecture par les pairs. Les objectifs sont assez divers :
- s’assurer que le nouveau comportement du produit suit bien les consignes métiers ;
- vérifier que le code suit bien nos conventions de code, qu’il est facilement maintenable, qu’il ne pose pas de soucis de performances ou de sécurité ;
- partager la connaissance de la base de code pour réduire le bus factor ;
- faire monter en compétences techniques les développeurs les plus juniors.
Le travail de relecture n’est pas un exercice évident, mais nous avons pu établir une liste de best practices.
Les commentaires laissés sur le code ne sont pas des paroles divines. Ils sont présents pour ouvrir une discussion, proposer une amélioration qui peut être contestée, ou mettre le doigt sur un problème. Chacun peut apporter son avis sur la question pour convaincre et faire converger les opinions, le tout avec bienveillance.
Squash & Merge
Une fois que tous les relecteurs ont approuvé la Pull Request et que tous les éléments nécessaires au déploiement en staging sont présents, le développeur assigné peut cliquer sur le bouton “Squash and merge”.
La responsabilité d’une modification du code ne repose pas sur une personne unique, celle qui clique sur le bouton, mais est partagée entre tous les participants. Ainsi, en cas de problème, la faute n’est pas jetée sur le développeur assigné à la tâche, ce qui pourrait causer quelques tensions inutiles au sein de la team.
La question du “Pourquoi un squash & Merge” a en partie été répondue plus haut. Mais ce type de commit s’est également révélé utile lorsque nous avons changé notre process de mise en production.
Enfin, le code est lancé dans notre ligne de déploiement continu (CD). C’est CircleCi qui déploie le code sur notre environnement de staging.
Si la tâche est validée par le Product Owner de la squad, elle partira sur le serveur de production lors du prochain déploiement. Dans le cas contraire, elle revient en développement.
Conclusion
L’étape du git flow la plus souvent négligée dans une team est très certainement celle de la code review : les aller-retours prennent trop de temps, les relecteurs ne produisent rien, le Product Manager met la pression pour que tout sorte plus vite, et si ça se trouve, personne n’a envie de la faire, cette review.
Nous mettons un point d’honneur à ce que tous les développeurs mettent la main à la pâte. Ce n’est pas le rôle d’un manager ou d’un lead dev de relire toutes les Pull Requests à heure fixe. Nous avons besoin de retours fréquents et de plusieurs points de vue — pas toujours le même !
Quant au problème de temps, il se compense de lui même par la suite. Si tout le monde est d’accord avec une implémentation, à priori il n’y aura pas besoin de revenir dessus tout de suite.
Nous bouclons ainsi le cycle de vie de notre git flow. La prochaine étape, la mise en production, est chez nous un processus assez élaboré qui nous permet de rester agile sur ce que nous souhaitons délivrer.
Si ça vous tente de faire des code reviews avec nous, on recrute !
