Croyez à l'utopie de simplification des merges et des branches

Nicola Paolucci
Nicola Paolucci
Retour à la liste

Les workflows de création de branche peuvent être bruts et simples ou complexes, solides et défensifs. De quel niveau de complexité et de protection votre entreprise a-t-elle besoin ? Ce billet s'intéresse au compromis entre l'agilité et la solidité. Il dispense, entre autres, certains conseils pour choisir votre propre expérience Git et explique les leçons qu'Atlassian a tirées de son expérience.

L'objectif de cet article est de vous donner les informations et les outils nécessaires pour choisir le modèle branching le plus efficace pour votre équipe.

Recommandations

  • Faites confiance au merge
  • Évitez les modèles de branching extrêmes.
  • Simplifiez et aplatissez les hiérarchies de branche dans la mesure du possible
  • Réfléchissez à la manière dont votre process de développement et vos outils influencent les décisions sur le modèle de création de branches.

Faites confiance au merge

Pour choisir le modèle de création de branches le plus adéquat, la première étape consiste à faire confiance au merge. Cette remarque s'applique aux équipes qui ont récemment fait l'acquisition de Git. Si vous avez franchi ce cap et adopté le merge, vous pouvez sauter ce paragraphe.

Tandis que vous pouviez être amené à prendre des mesures extrêmes (comme éviter les merges à tout prix ou engager une équipe spécialement dédiée à l'enfer du merge) dans les anciens systèmes, les merges sont tout sauf un problème dans Git. Et ce, pour plusieurs raisons :

  • Comme les branches sont rapides et peu onéreuses, Git favorise la création de branches éphémères, ainsi qu'une intégration rapide.
  • Dans Git, les merges se font toujours en local, c'est pourquoi leur effet est souvent instantané.
  • Git connaît l'ascendance de vos branches et fait uniquement un merge des commits concernés plutôt que de l'arborescence complète. Cela permet normalement de limiter les conflits.
  • Vous avez de nombreuses stratégies de merge à votre disposition. Elles vous feront aimer les merges, mais aussi la création de branches. La création de branches et les merges sont si simples que certaines équipes se retrouvent avec le problème opposé : elles vont trop loin avec ces fonctionnalités. Comme pour tout dans la vie, maintenez l'équilibre et n'en faites pas trop.

Évitez la création de branches à l'extrême.

Si vous vous intéressez aux modèles de création de branches en général (que ce soit avant ou après l'arrivée de Git), vous constaterez que certains présentent une structure simple, tandis que d'autres intègrent des couches. Les extrêmes peuvent poser problème. Dans tout cet embranchement, je vais vous exposer quelques cas souhaitables ou, au contraire, à exclure.

Branche unique extrême

Comme le disait jadis l'adage de Subversion : une branche pour les gouverner tous… Pendant des années, les équipes de développeurs (moi y compris) ont travaillé avec une seule branche, le trunk, contre vents et marées, que les fonctionnalités soient terminées ou non et que les builds fonctionnent ou boguent. Cette méthode fonctionnait et fonctionne toujours. Mais question efficacité, il y a mieux.

Le monde à une seule branche que nous aimions détester, avec lequel nous avons grandi et dans lequel certains d'entre nous travaillent encore ressemble à ceci :

trunk

Les équipes qui viennent d'adopter Git et celles qui veulent conserver leur workflow pourraient essayer de reproduire ce comportement. Même si le trunk dans git-speak se nomme à présent master, vous pouvez travailler avec une seule branche dans Git, ce qui donne :

Rebase on feature

Tout le monde travaille sur master, personne ne travaille sur des branches, et chaque développeur utilise rebase pour faire apparaître les derniers changements. Ce fonctionnement est très similaire à un ancien modèle de branching trunk-only sous Subversion.

J'entends souvent des équipes modernes qui (blague à part) ont adopté le modèle de création de branches à un certain niveau, mais appliquent, par nostalgie, une règle Squash sur un commit pour aplatir son historique afin d'obtenir un master semblable au schéma ci-dessus.

Que leur manque-t-il ? Du contexte et une certaine traçabilité. Pour en savoir plus, consultez mon billet Merge et rebase.

Quel est le principal inconvénient d'une branche unique ? Lorsque la branche master bogue, c'est tout le travail de l'équipe qui est perturbé. Il est vrai qu'avec Git, les développeurs ont accès à l'historique complet du projet. Il est très facile de revenir en arrière, avant que la panne ne se déclare, et de continuer à travailler jusqu'à ce que le problème soit réglé. Une autre chose est sûre : tout développeur parfaitement capable d'entreprendre ce voyage dans le temps créera ses propres branches en local pour y effectuer son travail.

Trop de couches sur les branches d'intégration

À l'inverse, il y a une organisation qui adore formaliser les process et qui utilise les branches en se compliquant la vie au lieu de la simplifier.

Examinons par exemple le modèle de branching suivant :

Trop de branches

Dans cet exemple, l'équipe crée une branche pour chaque user story ; à partir de chaque user story, une branche est créée pour chaque ticket ; et partir de chaque branche « issue », une branche est créée pour chaque sous-tâche. Le tout est intégré à la branche next, à partir de laquelle les développeurs livrent vers master.

Au risque de me répéter, la création de branches et les merges sont un véritable jeu d'enfant dans Git, mais compliquer le process pourrait influer sur la dynamique de votre équipe.

Simplifiez et aplatissez les hiérarchies de branche dans la mesure du possible

Au moins, nous savons à présent que nous devons éviter les extrêmes. Quel est donc le meilleur compromis entre structure et flexibilité ? Trouvez facilement la solution idéale pour votre équipe en répondant à quelques questions fondamentales :

  • De combien de branches longues ai-je besoin au minimum pour prendre en charge mon projet ?
  • Ai-je besoin de maintenir les anciennes versions de mon logiciel ou non ? En général, vous devez essayer d'aplatir les hiérarchies de branche autant que possible, en fonction de la robustesse de votre suite de test, de la confiance et du niveau de responsabilité que vous voulez accorder à votre équipe et de votre tolérance aux problèmes de production.

Chez Atlassian, nous utilisons un modèle de création de branches relativement plat dans plusieurs de nos équipes, dans nos produits derrière le pare-feu et dans notre offre à la demande (Cloud). 

Une branche par user story ou une branche par ticket (ticket Jira) ?

La granularité des branches est importante. Si elles sont trop épaisses et obligent certaines personnes à travailler ensemble, vous rencontrerez les problèmes de branche unique que j'ai mentionnés auparavant : lorsque vous créez (et publiez) trop de branches, votre processus de revue et la vision globale peuvent prêter à confusion et être surchargés.

We've found that a good granularity in choosing the scope of branches is "One branch per issue".

Workflow sain nº 1 : Master unique et stable. Utilisez des branches, mais faites en sorte qu'elles soient simples

Mon article récent sur les workflows Git élémentaires montrait un modèle de création de branches simple pour la livraison continue. En partant du principe que master est la branche de production. Tout commit ajouté à master est une livraison de production taguée. Ce workflow se prête notamment à la création d'applications Web, de façades de magasin et de SaaS, et plus généralement aux situations qui ne nécessitent pas de maintenir d'anciennes versions.

Workflow sain nº 2 : Recherchez la simplicité, mais conservez les anciennes livraisons

When you have to maintain and support older versions of your products a single stable master is not enough. The solution is to have a long running release branches for each version your team needs to support. Changes flow always from the older branches to the more recent ones, never in the opposite direction. For reason why see post on the essence of branch based workflows.

Branches de livraison longues

Branches d'intégration supplémentaires si nécessaire

À condition que vous sachiez exactement pourquoi vous ne pouvez pas faire autrement, il peut être utile d'isoler le travail d'une petite équipe de développeurs plus longtemps que nécessaire pour une seule itération. Pour ce faire, vous pouvez créer une branche d'intégration. Cette branche devra être mise à jour le plus souvent possible, à mesure que des changements seront apportés à master, afin de faciliter le merge final.

Par exemple, dans l'équipe Bitbucket Server, des branches d'intégration supplémentaires arrivent une à deux fois par cycle de livraison, qui dure, dans leur cas, environ six semaines. Celles-ci sont nécessaires lorsque l'équipe dispose de plusieurs flux de travail qu'elle doit isoler temporairement.

Le process de développement et les outils ont un impact sur le modèle de branching.

Le process de développement et les outils de votre équipe ont une influence considérable sur les décisions relatives au modèle de branching ainsi que sur son agilité et son efficacité.

Si vous utilisez les fonctionnalités Pull Request de Bitbucket Server ou Bitbucket Cloud, vous pouvez directement réviser le travail de vos pairs, sans écraser de branches dans un commit unique.

Au final, plus vous disposez d'informations sur le statut et les livrables de vos équipes, plus il sera facile pour tout le monde de travailler en parallèle.

Imaginez que vous puissiez, en un coup d'œil, vous renseigner sur le statut de tous les builds, des pull requests, des branches et des commits d'une fonctionnalité donnée. Excellente nouvelle : ce rêve est devenu une réalité. Appréciez cette merveille :

Panneau de développement JIRA

*Ce panneau de développement est disponible avec Jira 6.2, Bitbucket Server 2.10+ et Bamboo 5.4.

Vous voyez ci-dessus le panneau de développement dans Jira. Lorsqu'il est associé à Bitbucket et à Bamboo, vous disposez d'un emplacement unique pour effectuer toutes vos mises à jour de développement. Ce panneau, disponible dans tous vos tickets Jira et vos « Rapid Boards », permet à toutes les personnes impliquées dans le cycle de développement de travailler de manière synchronisée. Suivez le statut de vos branches, identifiez celles qui présentent des builds bugués et surveillez les déploiements sans avoir à rechercher à nouveau les infos. Consacrez votre temps à la programmation et à la livraison de code de qualité, plutôt qu'au suivi.

Conclusions

Ce billet s'est avéré plus long que prévu, mais j'espère qu'il vous a montré comment bien choisir et mettre en place un modèle de création de branches pour vos équipes. Suivez-moi (@durdn) et l'incroyable équipe @Bitbucket pour plus d'infos passionnantes sur DVCS.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant