Tout le monde connaît le workflow Gitflow, depuis longtemps connu et reconnu par la communauté Git. C’est souvent le choix par défaut lorsque l’on commence à utiliser un Version Controls System pour versionner son code, mais des alternatives se sont développées ces dernières années.

Dans cet article, nous rappellerons les principes de Gitflow pour ensuite le comparer à une de ses alternatives les plus populaires : le trunk-based development.

Qu’est-ce que Gitflow ?

Gitflow est le standard qui s’est imposé en matière d’organisation de son arborescence Git. Il se compose de plusieurs types de branches principales et temporaires. Certaines branches peuvent avoir une durée de vie importante avec des commits assez conséquents.

Voyons comment cela s’organise avec un schéma.

Nous avons la branche principale, appelée main (anciennement master), qui correspond à la version de l’application en production. Chaque commit sur master est une nouvelle version de l’application, taguée suivant la norme SemVer. Ainsi cette branche doit être toujours parfaitement stable.

La deuxième branche de base du Gitflow est Develop. Cette branche doit aussi être stable. Elle permet aux développeurs de mettre en commun le code issu de leurs branches respectives.

Quand un développeur se voit attribuer une tâche, il tire une branche de type feature de Develop. Il va réaliser un ensemble de commits puis rebase sa branche sur Develop pour la merger.

Une fois que plusieurs fonctionnalités ont été ajoutées à Develop, on peut en tirer une branche Release afin de préparer la mise en production. Cette branche sera déployée sur un environnement de recette (ou staging) et utilisée par les testeurs (QA Quality Assurance) et l’équipe produit afin d’en faire la recette. Une fois le travail validé, cette branche est mergée dans main. Si toutefois un problème était détecté en recette, un rapide commit de fix peut être ajouté, qui sera alors cherry-pick sur Develop.

Enfin, le type de branche Hotfix est utilisé pour corriger rapidement un problème apparu en production. On tire une branche depuis main, on effectue le commit de fix et on merge la branche dans main afin de versionner un commit de patch en production. Le commit est également cherry-pick sur Develop.

Les avantages de Gitflow

• Permet de travailler à plusieurs en parallèle sur des fonctionnalités différentes avec des branches qui peuvent durer assez longtemps
• La structure de l’historique est robuste, organisée
• Sécurise l’état du projet grâce aux différents mécanismes qui s’assurent que la version de master est toujours fonctionnelle
• Il est plus facile de naviguer entre les tickets fonctionnels et le code : chaque fonctionnalité a un ticket, une branche, une PR (Pull Request)

Les inconvénients de Gitflow

• Les conflits de merge sont plus compliqués à résoudre puisqu’il y a plus de code à merger à la fois
• L’architecture est assez rigide et ne favorise pas la spontanéité
• L’historique est plus dense et devient illisible si des rebases et des squashs ne sont pas utilisés
• Il peut être plus compliqué de corriger des bugs en suivant le workflow à la lettre car chaque PR contient beaucoup de code, il est donc plus difficile d’identifier la source du problème

Qu’est-ce que le trunk-based development ?

Dans trunk-based development, tout est basé sur la branche main, qui peut être appelée trunk et qui signifie tronc (penser à un tronc d’arbre duquel toutes les branches partent). Les développeurs créent des branches feature qui durent peu de temps, avec peu de commits et mergent très fréquemment de petits changements sur la branche principale. Cela assure une grande fluidité même quand la taille de l’équipe et la complexité du code augmentent.

Afin de déployer une nouvelle version en production, l’équipe peut tirer du trunk une branche de type Release, taguée avec le nouveau numéro de version.

Dans le cas où un bug est détecté en production, deux options se présentent :

• Le mieux est de reproduire le bug sur le trunk, le fixer en commitant sur le trunk et cherry-pick ce commit sur la branche de release pour déployer une version de patch (comme indiqué sur le schéma)
• Si l’identification du problème sur le trunk prend trop de temps et que le problème est critique, il peut être corrigé par un commit sur la branche de release et être cherry-pick sur le trunk. Mais cette méthode laisse le risque que le commit de fix soit oublié sur la branche de release et jamais appliqué sur le trunk

Les feature flags

Avec Gitflow, une fonctionnalité est mergée sur develop lorsqu’elle est totalement terminée, puis mergée sur main afin d’être déployée quand elle a été validée par toutes les parties prenantes.

Avec trunk-based development, un morceau de fonctionnalité peut être mergé sur le trunk et embarqué dans une release bien que la fonctionnalité ne soit pas terminée.

Afin d’éviter de se retrouver avec des comportements non désirés en production, il est courant d’utiliser des feature flags ou toggles. Ceux-ci consistent en un bout de code entourant la fonctionnalité en cours de développement afin de déterminer sur quels environnements celle-ci doit être appliquée.

Avantages du trunk-based development

Ce workflow est particulièrement adapté aux petites équipes puisqu’il simplifie le merge et l’identification de bugs. Il est également nettement plus simple que Gitflow. Les commits fréquents permettent de réduire la complexité du debug car les développeurs séparent le code qui cause le bug de la version en production.

Trunk-based development permet aussi de :

• Faciliter et accélérer le déploiement du code et des fixs
• Faciliter les code-reviews : il est plus simple et efficace de review quelques dizaines de lignes à la fois que quelques milliers…De plus, avoir moins de code à relire incite à traiter plus rapidement une PR. Ces deux éléments réduisent le temps entre le moment où le code est écrit et le moment où le développeur doit repasser dessus pour appliquer les retours faits sur la PR. Réduire ce temps permet de réduire l’impact du context-switching : ce laps de temps dont le cerveau a besoin pour passer d’une tâche à une autre et se remettre en mémoire tous les éléments pour mener à bien la tâche. Le context-switching peut faire perdre beaucoup de temps dans des projets où les choses ont tendance à avancer lentement. Le trunk-based development améliore ainsi la vélocité générale du projet.
• Promouvoir l’intégration CI/CD : étant donné que les merge sur main sont très fréquents, la validation doit être automatisée. Avoir une solide base de tests unitaires, intégration et end-to-end qui se lancent à chaque PR ou merge est essentiel pour s’assurer du bon fonctionnement du projet à chaque instant et pouvoir déployer automatiquement sereinement.

Inconvénients du trunk-based development

Bien que trunk-based development ait beaucoup d’avantages, il a aussi quelques inconvénients :

• Accroît le risque d’introduction de bugs et de régressions puisque la QA n’est pas forcément faite après chaque merge
• Demande plus d’effort et de rigueur pour maintenir la branche principale propre
• L’accumulation de feature flags peut complexifier le code et il ne faut pas oublier de supprimer le flag une fois la feature adoptée en production

Quand utiliser Gitflow ?

Gitflow est tout indiqué pour un projet conséquent, avec un cycle de release régulier où la qualité est primordiale. Il permet à de nombreux développeurs de travailler simultanément sur une base commune. Chaque nouvelle version de l’application peut être testée rigoureusement et le code uniformisé et validé par l’ensemble de l’équipe grâce aux code reviews.Ainsi, il sera recommandé si l’équipe est majoritairement junior afin de pouvoir valider leur travail.

Quand utiliser trunk-based development ?

Trunk-based development convient particulièrement à un projet récent, un POC ou un MVP. En effet, ce workflow permet de gagner en vélocité et de délivrer de la feature plus rapidement puisque le développeur n’a pas besoin d’attendre plusieurs phases de validation avant de merger son travail, et de devoir revenir dessus plusieurs jours voire semaines après si des modifications sont nécessaires. Certaines équipes se soustraient même au processus de merge request !Cependant, un tel fonctionnement conviendra mieux à des développeurs expérimentés, autonomes et qui travaillent bien entre eux.

Il est conseillé d’avoir une équipe assez restreinte et de bien faire des branches les plus courtes possibles afin d’éviter des conflits trop importants.

Conclusion

Alors que Gitflow reste le workflow le plus courant, trunk-based apporte une démarche peut-être plus moderne et mérite qu’on s’y intéresse. Comme pour tout changement majeur de processus, la transition vers trunk-based doit être soigneusement gérée et adaptée aux besoins spécifiques de votre équipe. Bien qu'il puisse être difficile de passer sur ce modèle, les avantages qu'il offre en termes de simplicité et de promotion d'une culture DevOps peuvent améliorer considérablement la productivité de votre équipe et la qualité globale de votre code.

Par Inès Tagmouti