Trunk-Based Development

Qu’est-ce que Trunk-Based Development ?

Le Trunk-Based Development (TBD) est une stratégie de gestion des branches Git où les développeurs collaborent sur une seule branche appelée “trunk” et réalisent des modifications plus petites et fréquentes. Dans ce modèle, les branches sont rarement utilisées et, lorsqu’elles le sont, elles sont de courte durée, ne dépassant généralement pas quelques heures.

L’idée principale derrière cette stratégie est de limiter l’utilisation de branches de longue durée pour éviter le “merge hell” (enfer des fusions). Le processus de TBD repose sur le concept que les fonctionnalités doivent toujours être dans un état prêt à être déployé.

Comment fonctionne Trunk-Based Development ?

Dans cette approche, chaque développeur divise son travail en petits lots, qu’il fusionne directement dans le trunk ou la ligne principale. Les développeurs effectuent donc leurs commits directement dans le trunk, sans créer de branches secondaires.

Trunk-Based Development et CI/CD

Le Trunk-Based Development est un élément clé pour l’intégration continue (Continuous Integration) et la livraison continue (Continuous Delivery). En effectuant plusieurs modifications par jour directement dans le trunk et en fusionnant rapidement toute branche créée, les développeurs respectent les principes de l’intégration continue.

Cela accélère la publication de nouvelles fonctionnalités, rendant ainsi possible la livraison continue. En résumé, TBD crée l’environnement nécessaire à l’intégration continue et favorise des déploiements rapides.

Quand adopter Trunk-Based Development ?

Le Trunk-Based Development fonctionne généralement mieux lorsque vous avez une équipe de développeurs expérimentés et seniors, car ce type de flux de travail leur donne l’autonomie nécessaire pour accomplir leur travail.

Cependant, il est moins recommandé si vous avez une équipe de développeurs juniors dont vous devez surveiller de près le travail. Il n’est également pas fortement recommandé si vous gérez un projet open-source où vous pourriez avoir besoin d’un contrôle plus strict sur les modifications effectuées, car dans ce type de projet, n’importe qui peut contribuer.

La maturité du produit est un autre facteur à considérer dans la décision d’utiliser le Trunk-Based Development. Si le produit en est à ses débuts, la priorité est généralement de le rendre opérationnel rapidement. Pendant ce temps, pour un produit plus mature, vous pourriez vouloir surveiller de près les modifications apportées, de peur de perdre une grande quantité d’argent en fonction de la valeur de votre produit bien établi. Dans ce cas, vous pourriez envisager le feature branching.

Le Trunk-Based Development est souvent combiné avec les feature flags – ou interrupteurs de fonctionnalités, pour que toute nouvelle fonctionnalité puisse être déployée dès qu’elle est prête et retirée facilement en cas de bogues.

Les avantages de Trunk-Based Development

Échapper à l’enfer des fusions (merge hell)

Contrairement au feature branching, où les branches sont longues et de durée indéterminée, les branches dans Trunk-Based Development sont de courte durée, ne dépassant pas quelques heures. Cela élimine la tâche risquée de fusionner des branches de longue durée qui se sont séparées du trunk, ce qui entraîne moins de conflits ou ce que nous avons appelé précédemment « merge hell ». Cela nous amène au deuxième avantage du TBD.

Moins de conflits de fusion

En implémentant l’intégration continue, les développeurs envoient leurs modifications dans la branche partagée au moins une fois par jour, réduisant ainsi considérablement la probabilité de conflits de fusion.

Cela est dû au fait que les développeurs n’attendent pas longtemps pour intégrer leurs modifications, ce qui facilite la résolution des conflits qui peuvent survenir. Les bogues deviennent plus faciles à détecter et plus susceptibles d’être corrigés rapidement, garantissant une intégration fluide dans la ligne principale.

De plus, comme il n’y a généralement pas de branches, les développeurs envoient directement leur code dans le trunk, éliminant ainsi le besoin et les tracas de fusionner des branches de longue durée.

Des retours plus rapides

L’intégration continue des modifications dans le trunk permet des améliorations continues des fonctionnalités, car les développeurs sont en mesure de valider leurs modifications avec celles de leurs collègues.

Ceci est différent du feature branching où chaque développeur travaille indépendamment dans une branche, et les modifications apportées dans cette branche ne sont visibles qu’après leur fusion dans la branche principale, ce qui peut prendre des jours, voire des semaines.

En conséquence, Trunk-Based Development offre une meilleure visibilité, permettant aux développeurs de s’assurer que leurs modifications sont alignées et fonctionnent parfaitement avec les autres commits récents.

Des publications rapides

Des retours rapides mènent naturellement à des publications rapides. L’envoi de modifications régulières dans le trunk conduit à une gestion des releases plus efficace et à des déploiements plus fréquents. Avec un flux continu de travail intégré dans le trunk et des petits changements continus aux fonctionnalités publiées, les versions deviennent plus stables. Ces versions seraient alors prêtes à être déployées à tout moment.

Dans un environnement à rythme rapide, publier des mises à jour constantes et des améliorations aux fonctionnalités est une évidence. Trunk-Based Development est indispensable pour livrer ces versions plus rapidement et non seulement n’importe quelle version, mais une version de haute qualité avec significativement moins de bogues. Par conséquent, les nouvelles fonctionnalités atteignent l’utilisateur final beaucoup plus rapidement. En gros, utilisez Trunk-Based Development lorsque le temps est essentiel.

Utiliser avec précaution

Trunk-Based Development n’est pas sans faiblesses. Lorsque vous avez des développeurs ajoutant constamment des modifications dans le trunk, vous vous retrouvez dans un état constant de changement. Il est important de s’assurer que les développeurs récupèrent régulièrement les modifications depuis le trunk afin qu’ils ne se gênent pas les uns les autres tout en ajoutant de nouveaux commits.

Comme mentionné précédemment, il existe également des cas où implémenter Trunk-Based Development n’est pas judicieux. Dans ce cas, les développeurs devraient envisager d’autres méthodes de développement telles que le feature branching.

En résumé

En fin de compte, les avantages de cette technique dépassent largement ses faiblesses. Le choix de la méthode appropriée pour gérer le code source dépend de ce qui est le mieux pour votre équipe. Cependant, si vous cherchez à livrer des versions de haute qualité à vos clients tout en favorisant une collaboration efficace entre les développeurs, la stratégie simple consiste à implémenter cette pratique au sein de votre entreprise.