Trunk-based development
GitFlow est souvent présenté comme l'orthodoxie en matière de travail collaboratif. Ce modèle a ses mérites mais, comme tout outil, il doit être employé à bon escient. Si GitFlow est incontournable dans l'open-source, il n'est pas fait pour du SaaS (Software as a Service), où le versionnement n'est pas "vu" de l'utilisateur. Et ce de l'aveu même de son créateur, qui, visiblement, en a eu marre de se faire conspuer.
Et puis le modèle GitFlow nécessite de la rigueur. J'ai vu trop d'historiques Git ressembler aux aiguillages de la Gare du Nord ou à l'arbre généaolique incestueux des rois de France 👑
Le problème de GitFlow, c'est le "merge hell", auquel vous serez tôt ou tard confronté si vous vous évertuez à faire des feature branches à durée de vie longue : des conflits à n'en plus finir et des tests automatisés désespérément rouges. Le merge hell, c'est la négation de l'intégration continue.
Le trunk-based development, à l'opposé, consiste à travailler sur une branche unique, appelée "trunk" ou "main". Simple, brutal et beau 💙
Déroutant, à tout le moins. Et oui, ça fonctionne : Google, entre autres, travaille ainsi.
Pour aller au bout de l'exercice et être "extrême" comme il nous plaît, voici 2 propositions :
-
Ne faites pas de PR (Pull Request), préférez le pair-programming. Si vous voulez vraiment faire des PR, vous devrez faire des features branches, mais alors à durée de vie courte (<1 jour).
-
Ne vous arrêtez pas en si bon chemin et allez jusqu'au déploiement continu : chaque commit part en production. En plus d'être utile en tant que tel, cela vous évitera de devoir tirer une branche en cas de bug fix (cherry pick depuis main).
Quelles sont les clés de la réussite pour une équipe qui voudrait travailler ainsi ?
-
Eh bien déjà travailler sur de vraies user stories : si votre découpage c'est "front-end" et "back-end", il y a peu de chances que ça marche… Un des bénéfices du trunk-based development est donc de vous inciter à découper toujours plus finement, en considérant la valeur perçue par l'utilisateur.
-
Utiliser des feature toggles (a.k.a. feature flags) : une alternative aux feature branches, qui vous permet de pousser sur main une fonctionnalité dont le développement n'est pas achevé.
-
Automatiser les tests, de toutes sortes : unitaires, d'intégration, d'acceptance et end-to-end. La base de l'intégration continue.
Alors bien sûr, 'faut reconnaître qu'au début, "c'est du brutal…" Mieux vaudrait d'ailleurs faire l'essai tout seul ou toute seule sur un side project, histoire de vous mettre d'accord avec vous même avant d'en parler aux petits copains.
Mais, si cette pratique vous paraît impensable aujourd'hui, je gage sans difficulté que l'expérience vous fera changer d'avis.