Retour

24 juillet 2019

Feature Branch vs Trunk Based development

Software Development

Development SERIAL IT Switzerland

Difficile d’envisager un développement applicatif sans penser à son cycle de vie : le versioning – qui permet de gérer en parallèle différentes versions et évolutions d’un projet – est devenu incontournable pour la majorité des développements.

Lorsqu’il y a la nécessité de maintenir plusieurs versions d’une application, il est important de définir une stratégie efficace et claire, surtout si les équipes de développement sont importantes.

La méthode « Feature Branch[1] » est une approche qui consiste à créer une nouvelle branche pour chaque fonctionnalité qui sera développée. Cela permet à chaque développeur de travailler de manière isolée, sans déranger ou être dérangé par les changements qui peuvent avoir lieu sur le tronc commun. Ensuite, quand la fonctionnalité est prête, on peut l’intégrer (faire un merge) à la branche principale. La branche principale reste ainsi toujours stable.

[1] Git Feature Branch Workflow est une surcouche qui permet d’appliquer cette approche avec Git.

Si le schéma plus haut est relativement simple, on peut aussi l’illustrer le cadre d’un développement plus conséquent :

Cependant, si la Feature prend beaucoup de temps à être développée, il sera difficile de détecter les problèmes d’intégration rapidement, ce qui va à l’encontre des bonnes pratiques en matière d’intégration continue : plus les développements sont faits de manière isolée pendant une longue période, plus le travail pour obtenir une version stable, qui passe les tests d’intégration continue, sera potentiellement lourd. N’est ce pas à l’opposé de la philosophie de l’intégration continue, dont le fondement est de tester le plus fréquemment possible le code, afin  d’avoir un retour sur la qualité des développements au plus tôt ?

Une autre approche, nommée « Trunk Based », permet principalement d’éviter de s’arracher les cheveux lors des merges. Le principe est simple : tout le monde développe et soumet ses changements sur une seule branche, le Trunk. Quand il y a la nécessité de faire une release, on peut choisir manuellement certaines portions de code (cherry-pick) pour les intégrer. Les branches de releases ne sont jamais réintégrées sur le tronc principal. Les commit se font de manière courte et fréquente, par petites étapes.

On remarque ici que ce type de workflow est totalement compatible avec l’esprit d’un projet en intégration continue : quand tous les développeurs font des commit réguliers plusieurs fois par jour sur le tronc commun, cela facilite les tests d’intégration. Si quelque chose ne fonctionne pas, l’équipe est donc prévenue très rapidement. Et le retour en arrière (rollback), ou le refactoring ne sera alors pas aussi couteux qu’après plusieurs jours, voire plusieurs semaines de développement isolé.

Nous pouvons par exemple citer Google, Facebook, Microsoft (équipes Office) et Amazon, comme compagnies qui basent leurs développements sur ce type d’approche.

Enfin, si vous souhaitez creuser le sujet, sachez que d’autres approches sont possibles pour contourner les problématiques présentées ici, tout en maintenant des développements parallèles. On peut notamment citer les branches par abstraction, le concept de Feature Toogle, ou plus simplement la création de branches avec une durée de vie très courte.

Articles de la même catégorie

carre1 carre2 circle1 circle2 circle3 triangle1 triangle2 triangle3