Développement basé sur le tronc

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.