Branches de fonctionnalités : la voie vers l'excellence

Ou comment créer des branches de tâches pour y parvenir. Ou des branches de livraisons. C'est vous qui décidez.

Dan Radigan Dan Radigan

Pratiquement tous les systèmes de contrôle de versions prennent désormais en charge les branches, à savoir les environnements de travail indépendants issus d'une base de code centrale et dévolus à la gestion de la configuration. Selon votre système de contrôle de versions, la branche principale s'appellera master, mainline, default ou trunk. Les développeurs peuvent créer leurs propres branches à partir de la branche de code principale et les utiliser de façon indépendante. 

Pourquoi les branches sont-elles importantes ?

La création de branches facilite, pour les équipes de développeurs, la collaboration au sein d'une même base de code centrale. Lorsqu'un développeur crée une branche, le système de contrôle des versions crée une copie de la base de code à ce moment précis. Les modifications apportées à la branche n'affectent pas les autres développeurs de l'équipe. Toute cela est évidemment positif, dans le sens où les fonctionnalités en cours de développement peuvent générer de l'instabilité, ce qui serait extrêmement perturbant si tout le travail était effectué sur la ligne de code principale. Toutefois, les branches ne doivent pas vivre de façon confinée. Les développeurs peuvent facilement récupérer les modifications d'autres développeurs afin de collaborer sur les fonctionnalités et s'assurer que leur propre branche ne s'éloigne pas trop du master.

Astuce 

Les branches ne servent pas uniquement à travailler sur les fonctionnalités. Elles peuvent mettre l'équipe à l'abri de changements d'architecture importants, tels que la mise à jour des frameworks, des bibliothèques communes, etc.

Trois stratégies de création de branches pour les équipes agiles

Les modèles de création de branches diffèrent souvent d'une équipe à l'autre. De nombreux débats animent la communauté du logiciel à ce sujet. L'un des thèmes majeurs concerne la quantité de travail qui doit demeurer au sein d'une branche avant de faire l'objet d'un merge dans le master. 

Création de branches de livraisons

L'idée sous-jacente à la création de branches de livraisons est qu'une livraison est entièrement contenue dans une branche. Cela signifie que, vers la fin du cycle de développement, le gestionnaire de livraisons créera une branche à partir du master (par exemple, « branche de développement 1.1 »). Toutes les modifications apportées pour la livraison 1.1 doivent être appliquées deux fois : une fois à la branche 1.1, puis une fois à la branche master. L'utilisation de deux branches représente du travail supplémentaire pour l'équipe et il est facile d'oublier le merge des deux branches. Les branches de livraisons peuvent être complexes et difficiles à gérer, étant donné que beaucoup de personnes travaillent sur les mêmes. Nous avons tous été confrontés à la situation douloureuse consistant à devoir faire un merge avec un grand nombre de modifications différentes sur une même branche. Si vous devez créer une branche de livraisons, créez-la en restant aussi proche que possible de la version actuelle. 

Warning:

Release branching is an important part of supporting versioned software out in the market. A single product may have several release branches (e.g., 1.1, 1.2, 2.0) to support sustaining development. Keep in mind that changes in earlier versions (i.e., 1.1) may need to be merged to later release branches (i.e., 1.2, 2.0). Check out our webinar below to learn more about managing release branches with Git.

Création de branches de fonctionnalités

Les branches de fonctionnalités sont souvent associées à des balises de fonctionnalités, à savoir des « interrupteurs » qui activent ou désactivent une fonctionnalité dans un produit. Cela simplifie le déploiement du code dans le master et permet de contrôler à quel moment la fonctionnalité est activée. Le code peut ainsi être facilement déployé avant que la fonctionnalité ne soit exposée à l'utilisateur final. 

Conseil d'expert :

Another benefit of feature flags is that the code can remain within the build but inactive while it's in development. If something goes awry when the feature is enabled, a system admin can revert the feature flag and get back to a known good state rather than have to deploy a new build.

Création de branches de tâches

At Atlassian, we focus on a branch-per-task workflow. Every organization has a natural way to break down work in individual tasks inside of an issue tracker, like Jira Software. Issues then becomes the team's central point of contact for that piece of work. Task branching, also known as issue branching, directly connects those issues with the source code. Each issue is implemented on its own branch with the issue key included in the branch name. It’s easy to see which code implements which issue: just look for the issue key in the branch name. With that level of transparency, it's easier to apply specific changes to master or any longer running legacy release branch.

Étant donné que l'agilité est centrée sur les user stories, les branches de tâches se combinent parfaitement avec le développement agile. Chaque user story (ou correction de bogue) vit au sein de sa propre branche. Il est donc facile de visualiser les tickets en cours et ceux qui sont prêts pour la livraison. Pour vous plonger réellement dans la création de branches de tâches (parfois appelée création de branches de tickets ou branche par ticket), préparez un bol de popcorn et découvrez, ci-dessous, notre webinaire enregistré, l'un des plus plébiscités qui soient. 

Et maintenant, le double maléfique de la création de branches : le merge

Nous avons tous déjà souffert en tentant d'intégrer plusieurs branches dans une même application. Traditionnellement, les opérations de merge ont toujours été très douloureuses à cause des systèmes centralisés de contrôle des livraisons, tels que Subversion. En revanche, les systèmes plus récents de contrôle des livraisons, comme Git ou Mercurial, adoptent une approche différente en matière de suivi des versions de fichiers évoluant dans différentes branches.

Les branches ont tendance à avoir une durée de vie limitée. Leur merge est donc plus facile et elles sont plus flexibles sur l'ensemble de la base de code. Entre la possibilité de faire, de façon fréquente et automatique, des merges de branches dans le cadre de l'intégration continue (IC) et le fait que les branches, dont la durée de vie est courte, contiennent tout simplement moins de modifications, « l'enfer du merge » appartient au passé pour les équipes qui utilisent Git et Mercurial.

C'est ce qui fait que la création de branches de tâches est formidable ! 

Validez, validez, validez

A version control system can only go so far in affecting the outcome of a merge. Automated testing and continuous integration are critical as well. Most CI servers can automatically put new branches under test, drastically reducing the number of "surprises" upon the final merge upstream and helping to keep the main code line stable.