Le Trunk-Based Development, une solution radicale au "merge hell"
GitFlow ou les joies du Merge Hell
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éalogique 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, une solution radicale
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 deux propositions :
- Ne faites pas de Pull Request (PR), 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). Ou alors prenez soin de faire des rebase très fréquents.
- 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).
Ne partez pas la fleur au fusil
Ne vous lancez pas dans l'aventure sur la simple conviction que c'est une bonne idée, car vous risqueriez de déchanter. Il y a en effet deux grands prérequis :
- Automatiser les tests : comme vous partagez votre code très fréquemment avec l'équipe, plusieurs fois ou plusieurs dizaines de fois par jour, et que chaque commit est susceptible d'aller en production, vous ne pouvez pas compter sur de la non-régression manuelle. Les tests automatisés, de toutes sortes , sont vos amis, c'est de toute façon la base de l'intégration continue.
- Découper votre travail de manière fine, afin de pouvoir pousser votre production plus fréquemment sur main. L'idéal est d'effectuer un découpage fonctionnel en user stories , car vous livrez ainsi fréquemment de la valeur aux utilisateurs et obtenez du retour d'usage par la même occasion. Évitez donc le fameux découpage back-end / front-end, il y a généralement mieux à faire.
Sur ce second sujet, pensez également aux feature toggles (a.k.a. feature flags), qui vous permettent de désactiver une fonctionnalité en production tant que son développement n'est pas achevé. Probablement plus à envisager comme un dernier recours, mais un recours tout de même bien utile.
Alors bien sûr, 'faut reconnaître qu'au début, le Trunk-Based Development, "c'est du brutal…" Mieux vaudrait peut-être faire l'essai tout seul sur un side project, histoire de vous mettre d'accord avec vous même avant d'en parler aux petits copains. Pour le reste, si la pratique est de prime abord inconcevable pour de nombreux développeurs, l'expérience prouve que la pratique les fait souvent changer d'avis.