Trunk based development : c'est quoi et comment ça marche ?
Résumé
Le trunk based development, c'est quoi ? Tous les développeurs committent sur une branche partagée, main, au moins une fois par jour. Des branches courtes (moins de deux jours), des feature flags pour cacher le travail en cours, et une CI qui tourne sur chaque commit. Résultat : un code toujours livrable. Le rapport DORA 2021 indique que les équipes d'élite sont 2,3 fois plus susceptibles d'adopter ce modèle.
Trunk based development c'est quoi ?
Le trunk based development c'est quoi, exactement ? En une phrase : tous les développeurs de l'équipe envoient leur code dans une seule branche partagée, généralement appelée main, au moins une fois par jour. Pas de longues branches de fonctionnalités qui s'accumulent pendant trois semaines. Pas de conflit de fusion qui transforme un vendredi tranquille en week-end de galère. Google fait tourner 35 000 développeurs sur ce modèle. Voilà comment ça fonctionne, et ce que ça change concrètement dans votre équipe.
Le problème du "rapport_v2_FINAL_UTILISER_CETTE_VERSION.xlsx", version code
Vous avez déjà ouvert un dossier partagé pour y trouver rapport_v1.xlsx, rapport_v2_FINAL.xlsx et rapport_UTILISER_CETTE_VERSION_edits_jean.xlsx côte à côte ? Vous comprenez déjà exactement ce que le trunk based development cherche à éviter.
Ce scénario arrive dans les dépôts de code quand les équipes utilisent des branches de fonctionnalités à longue durée de vie. Quelqu'un ouvre une branche en semaine 1. Le reste de l'équipe continue à livrer. En semaine 3, cette branche a 40 commits de retard sur main. La fusionner devient un projet de week-end que personne ne veut. Les conflits s'accumulent. Le développeur qui a écrit le code a oublié pourquoi la moitié de ce code existe. On appelle ça le "merge hell".
Gitflow, l'alternative la plus enseignée, essaie de résoudre ce problème avec une structure formelle : des branches séparées pour les fonctionnalités, les releases et les hotfixes, chacune avec une durée de vie définie. La structure semble propre sur le papier. En pratique, les branches s'accumulent comme des versions de tableur dans un dossier partagé, et "le jour de l'intégration" devient "la semaine de l'intégration".
Le trunk based development prend le parti inverse : arrêtez d'accumuler de la dette d'intégration. Committez sur main. Aujourd'hui.
Tout le monde committe sur main. Tous les jours. C'est le principe.
La règle centrale est simple : tous les développeurs poussent leurs modifications vers le trunk partagé au moins toutes les 24 heures. Pas d'exception pour "je n'ai pas encore fini" : vous committez ce que vous avez, et vous vous assurez que ce que vous avez ne casse pas le build.
Ça semble risqué, jusqu'à ce que vous compreniez les mécanismes qui rendent ça sûr :
Branches courtes : vous pouvez encore utiliser des branches, mais elles vivent quelques heures, pas plusieurs semaines. Une branche qui dure plus de deux jours est un signal à investiguer.
Tests automatisés sur chaque commit : votre pipeline CI fait tourner la suite de tests immédiatement. Si quelque chose casse, vous le savez en quelques minutes, pas à la fin du sprint.
Feature flags : les fonctionnalités à moitié construites restent cachées derrière un interrupteur jusqu'à ce qu'elles soient prêtes à être livrées. Les utilisateurs ne voient jamais du travail incomplet, même si celui-ci est déjà dans le code de production.
Le résultat : un code toujours en état d'être livré. Pas "livrable après qu'on ait fusionné la branche de fonctionnalité et fait tourner la QA pendant une semaine", mais livrable maintenant si besoin. C'est la promesse fondamentale.
Les branches courtes : on les mesure en heures, pas en semaines
Dans le trunk based development, vous n'êtes pas interdit de branches. Vous êtes interdit de branches longues.
Une branche ouverte à 9h, travaillée dans la matinée, revue par un collègue après le déjeuner, et fusionnée sur main avant 17h, c'est exactement ce qu'il faut. Elle est assez petite pour être comprise en une lecture. Les conflits éventuels se règlent en quelques minutes.
Une branche qui vit trois semaines pendant qu'un développeur construit tout un système d'authentification en isolation, c'est le problème. Quand vient le moment de fusionner, l'équipe passe plus de temps à résoudre les conflits qu'elle n'en a passé à construire la fonctionnalité.
Le seuil pratique que la plupart des équipes trunk-based utilisent : si une branche n'a pas fusionné dans les deux jours, quelque chose doit changer. Soit la fonctionnalité est trop grande et doit être découpée en morceaux plus petits, soit elle a besoin d'un feature flag pour que le travail partiel puisse atterrir en toute sécurité.
Découper le travail en petits morceaux, c'est la vraie discipline que le trunk based development développe. Au lieu de "construire tout le tableau de bord", vous livrez "ajouter la couche de données", puis "ajouter le premier graphique", puis "câbler les filtres". Chaque morceau fusionne sur trunk, est testé et livré indépendamment. La fonctionnalité complète émerge de façon incrémentale sur plusieurs commits.
Ça semble plus lent. En pratique c'est plus rapide, parce que vous détectez les problèmes pendant que le contexte est encore frais et la surface encore petite.
Les feature flags : livrer du travail inachevé sans rien casser
Les feature flags (aussi appelés feature toggles) sont le mécanisme qui rend le trunk based development praticable quand une fonctionnalité ne peut pas être terminée dans une seule branche courte.
L'idée est simple : enveloppez la nouvelle fonctionnalité dans une condition qui ne s'active que quand un interrupteur spécifique est activé.
if (featureFlags.nouveauTableauDeBord) {
afficherNouveauTableauDeBord();
} else {
afficherAncienTableauDeBord();
}Le nouveau code est déployé en production. Il ne s'exécute simplement pas pour les utilisateurs jusqu'à ce que vous activiez l'interrupteur. Ce qui signifie :
Les développeurs peuvent committer du travail en cours sur trunk sans affecter personne.
La QA peut tester la fonctionnalité en production en activant le flag pour un utilisateur ou un environnement spécifique.
Un lancement devient un changement de configuration, pas un déploiement.
Si quelque chose casse, vous désactivez le flag sans rollback ni branche hotfix.
L'infrastructure de feature flags va d'une simple variable d'environnement vérifiée au démarrage jusqu'aux plateformes dédiées. Pour une équipe qui commence, un fichier de configuration ou une variable par environnement suffit. L'important, c'est la capacité, pas la complexité de l'outillage.
Quand le trunk based development n'est pas le bon choix
Il vaut la peine de le dire directement : le trunk based development n'est pas universellement meilleur. Il convient à des contextes spécifiques.
Évitez-le si :
Votre pipeline CI/CD n'est pas en place. Le trunk based development sans tests automatisés sur chaque commit n'est pas une stratégie de branchement, c'est un code cassé qui s'accumule vite. L'infrastructure de test doit être en place avant que le modèle de branchement puisse fonctionner.
L'équipe ne peut pas committer fréquemment par nature. Les équipes distribuées où les contributeurs travaillent de façon asynchrone sur plusieurs fuseaux horaires, ou les projets open source où les contributeurs soumettent des lots peu fréquents, auront du mal avec la cadence de commit quotidienne.
Vous êtes dans un environnement réglementé avec des fenêtres de release obligatoires. Certains secteurs exigent une validation externe, de longs cycles de QA et des pistes d'audit formelles par branche de release. Les branches de release structurées de Gitflow correspondent mieux à ce type de flux de travail.
La discipline d'équipe n'est pas encore là. Le trunk based development exige que chaque commit sur main passe tous les tests ou soit corrigé immédiatement. Si votre équipe tolère les builds cassés, le trunk partagé devient le problème de tout le monde.
Gitflow est un choix raisonnable pour les équipes avec des calendriers de release trimestriels, plusieurs fonctionnalités développées en parallèle par des squads séparés, ou des exigences de conformité qui imposent une isolation au niveau des branches. La question est l'adéquation honnête au contexte, pas quelle approche gagne sur le principe.
Passer de Gitflow au trunk based development sans crise
Si votre équipe est sur Gitflow et veut essayer le trunk based development, la migration n'a pas à être une bascule brutale.
Commencez par arrêter de créer de nouvelles branches à longue durée de vie. Les fonctionnalités commencées après la décision reçoivent des branches courtes. Les fonctionnalités déjà en cours sur des branches longues finissent sous l'ancien modèle. Les deux approches coexistent temporairement.
Avant de committer du travail inachevé sur trunk, vous avez besoin de feature flags en place. Mettre en place même un système de feature flags basique est le prérequis pour tout le reste. Sans ça, le trunk based development signifie livrer une interface incomplète aux utilisateurs en production.
Ensuite, imposez la CI sur la branche main : les tests automatisés tournent sur chaque push, les tests échoués bloquent la fusion, et personne ne fusionne sans un build qui passe. C'est la partie non négociable.
Enfin, définissez la règle des deux jours explicitement : toute branche de plus de deux jours déclenche une conversation sur quoi en faire. Découpez la fonctionnalité en plus petit, ajoutez un flag, ou livrez ce qui est déjà fait.
L'ajustement inconfortable que la plupart des équipes vivent : accepter que "partiellement complet" est une chose valable à committer, tant que c'est caché derrière un flag et que ça ne casse pas les tests existants.
Ce que le rapport DORA dit sur la vitesse de livraison
Les rapports DORA (DevOps Research and Assessment) sont ce qui se rapproche le plus d'une recherche empirique à grande échelle sur les pratiques des équipes de développement. Le rapport DORA 2021 a révélé que les équipes les plus performantes sont 2,3 fois plus susceptibles d'utiliser le trunk based development par rapport aux équipes moins performantes.
Les équipes d'élite dans le cadre DORA déploient plusieurs fois par jour, avec des délais entre le commit et la production mesurés en heures plutôt qu'en semaines. Le trunk based development est constamment corrélé avec ces résultats.
La nuance importante : la corrélation n'est pas la causalité. Les équipes très performantes adoptent le trunk based development parce qu'elles ont déjà investi dans la discipline sous-jacente : tests automatisés, infrastructure CI/CD solide, développeurs qui écrivent des changements petits et ciblés. Ces fondations passent en premier. Le trunk based development est le modèle de branchement qui convient à ce contexte, pas ce qui le crée.
Biscuit l'a compris depuis longtemps : un bon retriever ne cherche pas à rapporter trois balles à la fois. Un commit, une revue, une fusion. Good boy.
Ça vaut vraiment la peine de changer ?
Si votre équipe passe un temps significatif à chaque sprint sur des conflits de fusion, retarde des releases parce que "la branche de fonctionnalité n'est pas encore prête", ou a des branches ouvertes si longtemps que plus personne ne se souvient pourquoi elles existent, le trunk based development mérite une évaluation sérieuse.
La cadence de commit quotidienne est exigeante. L'infrastructure de feature flags demande de la mise en place. Le changement culturel prend quelques semaines. Mais le résultat, un code toujours livrable, des conflits de fusion mesurés en lignes et pas en fichiers, et des releases qui sont routinières plutôt que des crises, représente une amélioration réelle dans la façon dont l'équipe travaille.
Commencez petit : une équipe, un sprint, la CI qui tourne sur chaque push, les feature flags en place. Voyez ce qui change en quatre semaines.