Close

Développement basé sur le tronc

Découvrez pourquoi cette pratique de gestion du contrôle de version est courante parmi les équipes DevOps.

Portrait de Kev Zettler
Kev Zettler

Full Stack Web Developer


Le développement basé sur le tronc est une pratique de contrôle de version où les développeurs mergent de petites mises à jour fréquentes vers un « tronc » principal ou une branche principale. Étant donné qu'il simplifie les phases de merge et d'intégration, il contribue à rendre possible la CI/CD, et améliore la livraison de logiciels ainsi que les performances organisationnelles.

Lorsque le développement n'en était qu'à ses débuts, les programmeurs n'avaient pas le luxe des systèmes de contrôle de version actuels. Ils développaient plutôt deux versions de leur logiciel simultanément afin de pouvoir suivre les changements et de les annuler si nécessaire. Au fil du temps, ce processus s'est révélé coûteux, inefficace et nécessitait beaucoup de travail.

À mesure que les systèmes de contrôle de version ont évolué, divers styles de développement ont émergé. Les programmeurs ont ainsi pu trouver plus facilement les bugs, programmer en parallèle de leurs collègues et accélérer la cadence de livraison. Aujourd'hui, la plupart des programmeurs exploitent l'un des deux modèles de développement pour livrer des logiciels de qualité : Gitflow et le développement basé sur le tronc.

Popularisé en premier, Gitflow est un modèle de développement plus strict dans lequel seules certaines personnes peuvent approuver les changements apportés au code principal. Cela permet de maintenir la qualité du code et de réduire le nombre de bugs. Le développement basé sur le tronc est un modèle plus ouvert, puisque tous les développeurs ont accès au code principal. Cela permet aux équipes d'itérer rapidement et d'implémenter la CI/CD.

Qu'est-ce que le développement basé sur le tronc ?


Le développement basé sur le tronc est une pratique de contrôle de version où les développeurs mergent de petites mises à jour fréquentes vers un « tronc » principal ou une branche principale. C'est une pratique courante parmi les équipes DevOps et elle fait partie du cycle de vie DevOps, car elle simplifie les phases de merge et d'intégration. En fait, le développement basé sur le tronc est une pratique obligatoire pour la CI/CD. Les développeurs peuvent créer des branches éphémères avec quelques petits commits au lieu de créer des branches de fonctionnalités au long cours. Au fur et à mesure que la base de code se complexifie et que l'équipe s'élargit, le développement basé sur le tronc contribue à maintenir la fluidité des livraisons en production.

Gitflow et le développement basé sur le tronc


Gitflow est un modèle de branching Git alternatif qui utilise des branches de fonctionnalité longues et plusieurs branches primaires. Il dispose de davantage de branches plus longues et de commits plus importants que le développement basé sur le tronc. Dans ce modèle, les développeurs créent une branche de fonctionnalité et attendent que la fonctionnalité soit terminée pour la merger à la branche « trunk » principale. Ces branches de fonctionnalités longues nécessitent une plus grande collaboration lors du merge, car elles risquent davantage de dévier de la branche « trunk » et d'introduire des mises à jour conflictuelles.

Découvrir la solution

Développez et exploitez des logiciels grâce à Open DevOps

Matériel connexe

Comment passer à l'intégration continue ?

Gitflow dispose également de lignes de branche principales séparées pour le développement, les correctifs logiciels, les fonctionnalités et les livraisons. Différentes stratégies sont disponibles pour merger des commits entre ces branches. Puisqu'il y a plus de branches à gérer et entre lesquelles jongler, la complexité augmente, et l'équipe doit mener des sessions de planification supplémentaires ainsi qu'une revue.

Le développement basé sur le tronc est beaucoup plus simple, car il se concentre sur la branche principale en tant que source des corrections et des versions. Dans cette approche, la branche principale est supposée être toujours stable, aucun ticket ne doit être ouvert et elle doit être prête au déploiement.

Avantages du développement basé sur le tronc


Le développement basé sur le tronc est une pratique obligatoire pour l'intégration continue. Si les processus de développement et de test sont automatisés mais que les développeurs travaillent sur des branches de fonctionnalités isolées et longues, qui sont rarement intégrées dans une branche partagée, vous ne tirez pas pleinement parti de l'intégration continue.

Le développement basé sur le tronc élimine les problèmes d'intégration de code. Lorsque les développeurs terminent une nouvelle tâche, ils doivent merger le nouveau code dans la branche principale. Pourtant, ils ne devraient pas merger les changements apportés au tronc tant qu'ils n'ont pas vérifié que le build est fonctionnel. Pendant cette phase, des conflits peuvent survenir si des changements ont été apportés depuis le début des nouvelles tâches. En particulier, ces conflits se complexifient à mesure que les équipes de développement et la base de code évoluent. On les observe notamment lorsque les développeurs créent des branches distinctes qui dévient de la branche source et que d'autres développeurs mergent simultanément du code qui se chevauche. Heureusement, le modèle de développement basé sur le tronc réduit ces conflits.

Permet l'intégration continue du code

Le modèle de développement basé sur le tronc utilise un dépôt avec un flux régulier de commits vers la branche principale. L'ajout d'une suite de tests automatisés et d'une surveillance de la couverture de code pour ce flux de commits ouvre la voie à l'intégration continue. Lorsque le nouveau code est mergé dans le tronc, des tests automatisés d'intégration et de couverture de code s'exécutent pour valider la qualité du code.

Assure une revue de code continue

Dans le développement basé sur le tronc, les petits commits rapides optimisent la revue de code. Grâce à de petites branches, les développeurs peuvent rapidement voir et réviser les changements mineurs. Par rapport à une branche de fonctionnalité longue, dans laquelle un réviseur lit des pages de code ou inspecte manuellement de nombreux changements de code, cela est beaucoup plus facile.

Permet des livraisons consécutives du code en production

Les équipes doivent effectuer des merges quotidiens fréquents dans la branche principale. Le développement basé sur le tronc s'efforce de garder la branche « trunk » fonctionnelle, ce qui signifie qu'elle est prête à être déployée à chaque commit. Des tests automatisés, la convergence du code et les revues de code permettent de garantir qu'un projet de développement basé sur le tronc est prêt à être déployé en production à tout moment. L'équipe peut ainsi déployer fréquemment en production et fixer d'autres objectifs pour les livraisons en production quotidiennes.

Développement basé sur le tronc et CI/CD

À mesure que la CI/CD gagnait en popularité, les modèles de branche ont été affinés et optimisés, et le développement basé sur le tronc a connu un essor. Désormais, c'est une exigence de l'intégration continue. Grâce à l'intégration continue, les développeurs peuvent effectuer un développement sur le « tronc » et réaliser des tests automatisés qui s'exécutent après chaque commit vers le tronc. Cela permet de garantir que le projet est fonctionnel à tout moment.

Bonnes pratiques de développement basé sur le tronc


Le développement basé sur le tronc garantit que les équipes livrent le code rapidement et de manière cohérente. Voici une liste d'exercices et de pratiques qui vous aideront à affiner la cadence de votre équipe et à élaborer un calendrier de livraison optimisé.

Développez par petits lots

Le développement basé sur le tronc suit un rythme rapide de livraison du code en production. Si on le comparait à de la musique, on parlerait de staccato rapide composé de notes courtes et succinctes qui se succèdent. Les commits dans le dépôt seraient alors les notes de musique. Limiter la taille des commits et des branches permet d'accélérer les merges et les déploiements.

De petits changements de quelques commits ou la modification de quelques lignes de code minimisent la charge cognitive. Il est beaucoup plus facile pour les équipes d'avoir des conversations qui ont du sens et de prendre des décisions rapides lorsqu'elles révisent une zone limitée du code plutôt qu'un ensemble tentaculaire de changements.

Feature flags

Les feature flags complètent bien le développement basé sur le tronc en permettant aux développeurs d'encapsuler de nouveaux changements dans un chemin de code inactif et de l'activer ultérieurement. Les développeurs ne doivent ainsi pas créer une branche de fonctionnalité de dépôt distincte, et peuvent directement commiter le code des nouvelles fonctionnalités dans la branche principale, sans chemin de feature flag.

Les feature flags encouragent directement les mises à jour par petits lots. Au lieu de créer une branche de fonctionnalité et d'attendre le développement de la spécification complète, les développeurs peuvent créer un commit dans le tronc qui introduit le feature flag et pushe les nouveaux commits qui spécifient la fonctionnalité au sein du flag.

Implémentez des tests automatisés exhaustifs

Des tests automatisés sont nécessaires pour tout projet logiciel moderne ayant l'intention de faire appel à la CI/CD. Il existe plusieurs types de tests automatisés qui s'exécutent à différentes phases du pipeline de livraison. Des tests unitaires et d'intégration à court terme sont exécutés pendant le développement et lorsque le code est mergé. Les tests complets, de bout en bout et de plus longue durée sont exécutés au cours des phases ultérieures du pipeline dans un environnement de staging complet ou de production.

Les tests automatisés facilitent le développement basé sur le tronc en maintenant une cadence peu élevée lorsque les développeurs mergent de nouveaux commits. La suite de tests automatisés passe en revue le code pour tous les tickets et l'approuve ou le refuse automatiquement. Cela permet aux développeurs de créer rapidement des commits et de les soumettre à des tests automatisés pour voir s'ils introduisent de nouveaux problèmes.

Effectuez des revues de code asynchrones

Dans le développement basé sur le tronc, la revue de code doit être effectuée immédiatement et ne pas être placée dans un système asynchrone pour révision ultérieure. Les tests automatisés assurent une revue anticipée du code. Lorsque les développeurs sont prêts à passer en revue une pull request d'un membre de l'équipe, ils peuvent d'abord vérifier que les tests automatisés ont réussi et que la couverture du code a augmenté. Cela donne au réviseur l'assurance immédiate que le nouveau code répond à certaines spécifications. Il peut alors se concentrer sur des optimisations.

Dans le dépôt de code de l'application, n'ayez pas plus de trois branches actives

Une fois qu'une branche est mergée, il est recommandé de la supprimer. Un dépôt comprenant de nombreuses branches actives présente quelques inconvénients fâcheux. S'il peut être bénéfique pour les équipes de voir quelle tâche est en cours en examinant les branches actives, ce n'est pas le cas lorsque des branches caduques et inactives perdurent dans le dépôt. Certains développeurs utilisent des interfaces utilisateur Git qui peuvent s'avérer compliquées lorsqu'ils doivent charger un grand nombre de branches distantes.

Mergez les branches dans le tronc au moins une fois par jour

Les équipes ultra performantes s'appuyant sur le développement basé sur le tronc doivent fermer et merger toutes les branches ouvertes et prêtes à être mergées au moins une fois par jour. Cet exercice aide à maintenir la dynamique et établit une cadence pour le suivi des versions. À la fin de la journée, l'équipe peut alors étiqueter le tronc principal en tant que commit de livraison, ce qui a pour effet secondaire de générer un incrément de livraison Agile.

Réduisez le nombre de gels du code et de phases d'intégration

Lors des phases d'intégration, les équipes de CI/CD Agile ne devraient pas avoir besoin de gels du code planifiés ou de s'interrompre bien qu'une organisation puisse devoir le faire pour d'autres raisons. Le terme « continu » dans CI/CD implique que les mises à jour affluent constamment. Les équipes de développement basé sur le tronc devraient éviter les gels de code qui peuvent devenir bloquants et planifier en conséquence pour s'assurer que le pipeline de livraison n'est pas bloqué.

Développez rapidement et exécutez immédiatement

Afin de maintenir une cadence de livraison rapide, il est important d'optimiser les temps d'exécution de développement et de test. Les outils de développement CI/CD doivent utiliser des couches de mise en cache lorsque cela est approprié afin d'éviter les calculs coûteux pour les statiques. Les tests doivent être optimisés pour utiliser les ébauches appropriées pour les services tiers.

Conclusion…


Le développement basé sur le tronc est actuellement la norme pour les équipes d'ingénierie ultra performantes puisqu'il établit et maintient une cadence de livraison de logiciels en utilisant une stratégie de création de branche Git simplifiée. De plus, le développement basé sur le tronc offre aux équipes d'ingénierie plus de flexibilité et de contrôle sur la façon dont elles livrent des logiciels à l'utilisateur final.

Atlassian Bitbucket possède des capacités de CI/CD intégrées qui permettent un développement basé sur le tronc. Essayer maintenant.

Kev Zettler
Kev Zettler

Entrepreneur accompli, Kev Zettler est développeur web principal complet et dispose de plus de dix années d'expérience dans le développement de produits et la création d'équipes à l'aide des méthodologies Agile. Il est un contributeur, auteur et formateur passionné par les technologies open source émergentes telles que DevOps, les crypto-monnaies et la RV/RA. Durant son temps libre, il participe au développement de jeux vidéo indépendants.


Partager cet article

Lectures recommandées

Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.

Illustration DevOps

Communauté DevOps

Illustration DevOps

Lire le blog

Illustration d'une carte

Essayez la solution gratuitement

Inscrivez-vous à notre newsletter DevOps

Thank you for signing up