Feature branch

Qu’est-ce qu’une feature branch ?

Lorsque plusieurs développeurs travaillent sur la même base de code, il serait difficile pour eux de travailler sans que leurs travaux se chevauchent ou outrepassent les changements de l’autre.

La solution simple pour eux est de faire une copie de la base de code afin que chaque développeur puisse travailler sur ses propres fonctionnalités. Imaginez-le comme un arbre où la branche principale peut être appelée le tronc (aussi appelé main ou mainline) et chaque copie de la base de code est appelée une branche. Ensuite, lorsque l’équipe estime que la fonctionnalité est prête, elle fusionne cette fonctionnalité au tronc commun.

Le processus d’intégration de toute modification apportée au tronc principal est connu sous le nom de fusion. Le développement et la fusion de branches de fonctionnalités sont gérés dans des logiciels de contrôle de version tels que Github, GitLab ou Bitbucket 

Les avantages du feature branching 

Pour simplifier, chaque fois qu’un développeur veut travailler sur une fonctionnalité, il ouvre une branche où il fera tout le travail sur la fonctionnalité dans cette branche, puis une fois que ce sera terminé, ils intégreraient ces changements avec le reste de l’équipe en effectuant l’intégration de la mainline une fois la fonction terminée. 

Collaboration

Une branche de fonctionnalité, en ce sens, permet aux développeurs de collaborer de manière efficace autour d’une base de code centrale en conservant toute modification d’une fonctionnalité dans une branche spécifique afin que les modifications n’affectent pas les autres développeurs.

Une feature branch permet également aux équipes agiles de détecter les bugs lorsque chaque bug vit dans sa propre branche, ce qui leur permet de voir quels problèmes sont en cours et lesquels sont prêts pour la publication. Cela se fait au moyen de demandes d’extraction où tout changement peut être discuté avant de le fusionner au master en donnant aux développeurs la possibilité d’examiner ces changements avant qu’ils ne soient finalement fusionnés dans le mainline.

En résumé, le principe de base qui sous-tend ce concept, selon Martin Fowler:

« Mettre tout le travail pour une fonctionnalité sur sa propre branche, intégrer dans la ligne principale lorsque la fonctionnalité est terminée »

Les inconvénients des feature branches

Des conflits de fusion

D’une part, le développement axé sur les fonctionnalités permet de gérer des projets à grande échelle en accordant des ressources en fonction des besoins de chaque fonctionnalité.

D’autre part, il peut, à un moment donné, devenir difficile de gérer des milliers de branches. Par exemple, si une branche caractéristique reste en développement trop longtemps, alors elle pourrait entrer en conflit avec d’autres branches lors de la fusion. Il se peut qu’une branche fonctionne parfaitement bien toute seule, mais une fois fusionnée, elle ne fonctionne plus en raison des changements qui ont eu lieu dans la ligne principale entre-temps.

Cela retarde le déploiement, car il faut souvent analyser de nombreuses demandes de téléchargement pour résoudre les conflits de fusion, et car il faut souvent analyser de nombreuses demandes de téléchargement pour résoudre les conflits de fusion.

À titre d’exemple, imaginons une situation où la fonctionnalité d’un développeur ne peut pas être publiée indépendamment jusqu’à ce que la fonctionnalité de l’autre développeur soit complète. Cela signifie que de multiples flux de travail indépendants deviennent si enchevêtrés que l’un ne peut être diffusé sans l’autre, ce qui signifie que ces fonctionnalités ne peuvent pas être diffusées indépendamment. La solution semble assez simple, c’est-à-dire l’utilisation de feature branching. Mais maintenant le problème des fusions douloureuses se pose surtout quand les développeurs travaillent séparément sur différentes branches dans des délais différents sans aucune intégration et donc sans pousser le code en continu vers une branche partagée. 

En résumé, il y a un risque de conflits majeurs de fusion lorsque les branches parallèles contiennent des changements significatifs. Cela donne lieu à ce qu’on appelle l’« enfer de la fusion », qui résulte de la fusion de plusieurs branches à longue durée de vie, ce qui peut être évité si vous fusionnez dans le tronc plusieurs fois par jour 

Feature branching utilisant les feature flags

La meilleure solution est d’utiliser les feature flags et de pratiquer l’intégration continue. Les feature branches sont souvent associées à des feature flags  pour permettre l’activation et la désactivation d’une fonctionnalité et lui permettre d’être montré à un sous-ensemble d’utilisateurs sélectionnés. Dans la branche des fonctionnalités, la gestion de déploiement des versions est liée aux déploiements de code. 

C’est là que les flags sont utilisés. L’utilisation de flags permet de transférer les changements en cours dans une branche partagée sans bloquer la version de cette branche afin que les développeurs puissent déployer la fonctionnalité terminée tout en gardant les fonctionnalités incomplètes désactivées. Par conséquent, les développeurs sont en plein contrôle des cycles de vie des fonctionnalités sans compter sur les déploiements de code.

Nous pouvons donc conclure que feature branching est une technique utile pour permettre à tout le travail effectué d’être tenu à l’écart de la base de code partagée jusqu’à ce qu’elle atteigne son terme. Pour être en mesure d’obtenir des résultats optimaux avec le feature branching, il est souvent nécessaire de compléter les fonctionnalités dans un jour ou deux au plus, car les équipes qui prennent des semaines ou des mois pour terminer une fonctionnalité vont rencontrer des difficultés. 

Dans d’autres situations où les équipes sont à la recherche d’une version de produit efficace grâce à un feedback rapide, elles se tournent vers l’intégration continue, ce qui aide à réduire les conflits de fusion en fusionnant continuellement tous les changements dans le mainline. Les développeurs qui utilisent cette méthode, appelée trunk-based development, poussent le code directement dans le tronc dès que possible, généralement en moins d’une journée, donc lorsque les développeurs créent une branche, elle ne reste généralement pas longtemps.