Le développement axé sur le tronc est l'une des stratégies de branching fréquemment utilisées par les équipes pratiquant l'intégration et la livraison/déploiement continus (CI/CD).
Dans le cadre d'un développement axé sur le tronc, vous validez les modifications directement sur la branche de référence (c'est-à-dire le tronc), plutôt que de développer des fonctionnalités ou des corrections de bogues dans des branches séparées pour les fusionner ultérieurement à la branche de référence.
La validation des modifications dans la branche de référence déclenche le pipeline CI/CD. Si le pipeline signale des défaillances, il incombe à toutes et tous d'intervenir pour tenter d'y remédier le plus rapidement possible. L'objectif est de garder la branche de référence dans l'état déployable, avec des modifications publiées fréquemment.
Si vous connaissez déjà les principes de la CI/CD, vous avez probablement compris d'après la description ci-dessus que le développement axé sur le tronc convient bien à l'intégration et au déploiement continus. Tant que tous les membres de votre équipe valident régulièrement leurs modifications, vous bénéficiez de la visibilité des modifications apportées par chacun et d'un retour d'information régulier et rapide sur l'avancement du projet.
La primauté du maintien de la propreté de la branche de référence et de son état publiable encourage chacun à tester ses modifications au fur et à mesure. Le suivi des statistiques de couverture des tests vous aidera à garder un œil sur ce point, tandis qu'en vérifiant que tout le monde génère des builds localement (peut-être aussi à l'aide d'un ensemble basique de tests automatisés) avant de valider, vous réduirez le nombre de problèmes détectés dans la version de référence.
Certain·es adeptes du développement axé sur le tronc affirment que c'est le seul moyen de réaliser l'intégration continue et que l'utilisation de branches de développement ou de fonctionnalités ne fait que miner les avantages de l'intégration continue. Toutefois, le développement axé sur le tronc présente lui aussi des inconvénients.
Bien qu'il convienne parfaitement au déploiement continu, où les modifications du code qui passent toutes les étapes du pipeline sont publiées automatiquement, le modèle fonctionne mieux pour les produits SaaS (logiciel en tant que service), où règne une forte tolérance (voire une attente) pour les mises à jour continues.
Si vous créez un produit installé ou une application mobile, vous souhaiterez peut-être regrouper les modifications dans des versions périodiques plutôt que de créer une nouvelle version pour chaque mise à jour qui passe par le pipeline.
Dans ce cas, l'utilisation de branches facilite la gestion des éléments inclus dans chaque version et assure une prise en charge continue de plusieurs versions du produit.
Votre façon de gérer le développement de fonctionnalités importantes ou complexes peut soulever des problèmes dans le contexte d'un développement axé sur le tronc. La validation régulière des modifications dans la version de référence tout en les déployant directement en production suppose un moyen de gérer les fonctionnalités que vous ne souhaitez pas encore rendre visibles pour les utilisateurs et utilisatrices.
Dans un développement axé sur le tronc, les drapeaux de fonctionnalités permettent de contrôler la visibilité des fonctionnalités, mais leur gestion peut être complexe. Une autre solution consiste à opter pour une stratégie de branching qui comprend des branches de fonctionnalités, afin de séparer les fonctionnalités jusqu'à ce que vous soyez prêt à les publier.
Pour les équipes qui n'ont pas encore adopté la CI/CD, il peut s'avérer difficile, avant d'avoir eu le temps de développer une suite de tests solide, de valider des modifications directement dans la version de référence en s'assurant qu'elle reste déployable. Si le développement axé sur le tronc était sans cela votre choix idéal, il vaut la peine d'en faire un objectif à atteindre au fil de la maturation de votre pratique de la CI/CD.
Le développement axé sur le tronc est adapté à l'intégration et au déploiement continus. Son fonctionnement est optimal si vous disposez d'une suite de tests automatisés robuste et si vous n'avez pas besoin de prendre en charge plusieurs versions de votre logiciel ou de regrouper les mises à jour dans des versions. Toutefois, ce n'est certainement pas la seule solution et d'autres stratégies de branches peuvent s'avérer plus adaptées, en fonction de votre situation.