Dans le monde actuel du dĂ©veloppement de logiciels, la vitesse et l’agilitĂ© sont cruciales lorsqu’il s’agit de dĂ©velopper et de sortir un logiciel . Cependant, lorsqu’une grande Ă©quipe de dĂ©veloppeurs travaille simultanĂ©ment, les branches et les fusions de code peuvent rapidement devenir dĂ©sordonnĂ©es.
C’est pourquoi les Ă©quipes doivent mettre en place un processus permettant d’implĂ©menter plusieurs changements Ă la fois. C’est la raison pour laquelle la mise en place d’une stratĂ©gie de branches efficace devient une prioritĂ© pour ces Ă©quipes.
Qu’est-ce qu’une stratĂ©gie de branches ?
Les branches sont utilisées essentiellement comme un moyen pour les équipes de développer des fonctionnalités en leur donnant un espace de travail séparé pour leur code. Ces branches sont généralement rattachées à la branche principale une fois le travail terminé. De cette manière, les fonctionnalités, les bugs et les corrections de bugs sont séparés les uns des autres, ce qui permet de corriger les erreurs plus facilement.
Cela signifie que les branches protègent la chaĂ®ne principale du code et que les modifications apportĂ©es Ă une branche donnĂ©e n’affectent pas les autres dĂ©veloppeurs.
Une stratĂ©gie de branches est donc la stratĂ©gie que les Ă©quipes de dĂ©veloppement de logiciels adoptent lorsqu’elles Ă©crivent, fusionnent et dĂ©ploient du code en utilisant un système de contrĂ´le de version.
Il s’agit essentiellement d’un ensemble de règles que les dĂ©veloppeurs peuvent suivre pour dĂ©terminer comment interagir avec une base de code partagĂ©e.
Une telle stratĂ©gie est nĂ©cessaire car elle permet de maintenir les rĂ©fĂ©rentiels organisĂ©s afin d’Ă©viter toute erreur dans une application et l’enfer de la fusion, redoutĂ© lorsque plusieurs dĂ©veloppeurs travaillent simultanĂ©ment et ajoutent toutes leurs modifications en mĂŞme temps.
De tels conflits de fusion finiraient par dĂ©courager l’envoi rapide de code et par empĂŞcher la crĂ©ation et le maintien d’un processus DevOps efficace, car l’objectif principal de DevOps est de crĂ©er un flux de travail rapide qui permette la publication de petits lots de code.
Ainsi, l’adhĂ©sion Ă une stratĂ©gie de branches permet de rĂ©soudre ce problème afin que les dĂ©veloppeurs puissent travailler ensemble sans se marcher sur les pieds. En d’autres termes, cette stratĂ©gie permet aux Ă©quipes de travailler en parallèle afin d’obtenir des versions plus rapides et de rĂ©duire les conflits en crĂ©ant un processus clair pour les modifications apportĂ©es au code source.
Lorsque nous parlons de branches, nous faisons référence à des lignes de code indépendantes qui partent de la branche principale, permettant aux développeurs de travailler indépendamment avant de fusionner leurs modifications avec le code source.
Dans cet article, nous décrirons quelques-unes des stratégies de branches utilisées par les équipes pour organiser leur flux de travail et nous examinerons leurs avantages et leurs inconvénients, ainsi que la stratégie que vous devriez choisir en fonction de vos besoins, de vos objectifs et des capacités de votre équipe.
Pourquoi avez-vous besoin d’une stratĂ©gie de branches ?
Comme indiquĂ© ci-dessus, il est nĂ©cessaire d’avoir une stratĂ©gie de branches pour Ă©viter les conflits lors de la fusion et pour faciliter l’intĂ©gration des modifications au tronc principal.
Une stratégie de branches vise à :
Améliorer la productivité en assurant une bonne coordination entre les développeurs.
Permettre un développement en parallèle.
Aider à organiser une série de releases planifiées et structurées.
Etablir un processus clair lorsque des modifications sont apportées au logiciel en vue de sa mise en production.
Maintenir un code exempt de bugs dans lequel les développeurs peuvent rapidement corriger les problèmes et remettre ces modifications en production sans perturber le flux de développement.
Git Branching
Les branches ne sont pas réservées à Git. Cependant, dans cet article, nous nous concentrons sur Git en raison des nombreux avantages que ce modèle de branches offre.
Par conséquent, avant de nous plonger dans les différentes stratégies de branches existantes, y compris les stratégies de branches de Git, nous allons examiner comment Git gère les branches et pourquoi il se distingue des autres outils de contrôle de version.
En termes simples, Git et les autres outils de contrĂ´le de version permettent aux dĂ©veloppeurs de suivre, de gĂ©rer et d’organiser leur code.
Les branches Git permettent aux dĂ©veloppeurs de s’Ă©carter de la branche principale en crĂ©ant des branches distinctes pour isoler les modifications du code. La branche par dĂ©faut de Git est la branche principale.
Le principal avantage d’une branche Git est qu’elle est « lĂ©gère », ce qui signifie que les donnĂ©es sont constituĂ©es d’une sĂ©rie de snapshots. Ainsi, Ă chaque validation, Git prend une photo de vos fichiers Ă ce moment-lĂ et stocke une rĂ©fĂ©rence Ă ce snapshot. Cela signifie que ces branches ne sont pas de simples copies du système de fichiers, mais simplement un pointeur vers le dernier dĂ©pĂ´t.
En revanche, d’autres outils de contrĂ´le de versions stockent les informations sous la forme d’une liste de modifications basĂ©es sur des fichiers, ce qui peut ralentir le processus et occuper beaucoup d’espace.
Dans Git, une branche est essentiellement une rĂ©fĂ©rence ou un pointeur vers le dernier changement dans un contexte donnĂ© ; ce n’est pas un conteneur pour les changements. Au fur et Ă mesure que vous crĂ©ez de nouvelles modifications dans la nouvelle branche, Git crĂ©e de nouveaux pointeurs pour suivre ces changements. Les branches Git peuvent donc ĂŞtre considĂ©rĂ©es comme un pointeur vers un instantanĂ© de vos modifications.
Les images ci-dessous illustrent ce concept : l’image du haut montre la branche main et un pointeur pointant vers le dernier dĂ©pĂ´t, et l’image juste en dessous montre ce qui se passe lorsque vous crĂ©ez une nouvelle branche appelĂ©e  » dev « : un nouveau pointeur pointe dĂ©sormais vers le dernier dĂ©pĂ´t.
En rĂ©sumĂ©, le modèle de branches de Git est plus lĂ©ger que celui des autres systèmes de contrĂ´le de version ; c’est pourquoi il est si facile et peu coĂ»teux de crĂ©er des branches dans Git , car il n’est pas nĂ©cessaire de copier l’ensemble du code dans la branche, ce qui crĂ©e un grand nombre de fichiers en double, contrairement Ă d’autres outils de contrĂ´le de version.
Quelles sont les stratégies de branches les plus fréquentes avec Git ?
GitFlow
Considéré comme assez compliqué et avancé pour de nombreux projets actuels, GitFlow permet un développement parallèle dans lequel les développeurs peuvent travailler sur des fonctionnalités séparément de la branche principale, grâce à une branche de fonctionnalités créée à partir de celle-ci.
Ensuite, lorsque les modifications sont terminées, le développeur les fusionne avec la branche principale pour la publication.
Cette stratégie de ramification se compose des branches suivantes :
La branche principale
Le développement
La fonctionnalité : pour développer de nouvelles fonctionnalités à partir de la branche de développement.
La release : permet de préparer une nouvelle release production. Elle est généralement dérivée de la branche de développement et doit être fusionnée à la fois à la branche de développement et à la branche principale.
Hotfix : aide Ă©galement Ă prĂ©parer une release. Cependant, contrairement aux branches release, les branches hotfix sont issues d’un bug qui a Ă©tĂ© dĂ©couvert et qui doit ĂŞtre rĂ©solu. Elles permettent aux dĂ©veloppeurs de continuer Ă travailler sur leurs propres modifications sur la branche de dĂ©veloppement pendant que le bug est en train d’ĂŞtre corrigĂ©.
Les branches principale et de développement sont considérées comme les branches principales, avec une durée de vie infinie, tandis que les autres sont des branches de soutien destinées à faciliter le développement parallèle entre les développeurs, généralement de courte durée.
Les avantages et les contraintes de GitFlow
L’avantage le plus Ă©vident de ce modèle est qu’il permet un dĂ©veloppement parallèle afin de protĂ©ger le code de production, de sorte que la branche principale reste stable pour la publication pendant que les dĂ©veloppeurs travaillent sur des branches sĂ©parĂ©es.
En outre, les diffĂ©rents types de branches permettent aux dĂ©veloppeurs d’organiser plus facilement leur travail. Cette stratĂ©gie contient des branches distinctes et directes pour des objectifs spĂ©cifiques, bien qu’elle puisse devenir compliquĂ©e pour de nombreux cas d’utilisation.
Elle est également idéale pour gérer plusieurs versions d’un même code de production.
Cependant, au fur et Ă mesure que des branches sont ajoutĂ©es, elles peuvent devenir difficiles Ă gĂ©rer car les dĂ©veloppeurs fusionnent leurs modifications de la branche de dĂ©veloppement Ă la branche principale. Les dĂ©veloppeurs devront d’abord crĂ©er la branche de publication, puis s’assurer que tout travail final est Ă©galement fusionnĂ© dans la branche de dĂ©veloppement, avant de fusionner cette branche de publication dans la branche principale.
Si les modifications sont testées et que le test échoue, il devient de plus en plus difficile de déterminer où se situe exactement le problème, car les développeurs sont perdus dans une masse de modifications.
En effet, la complexitĂ© de GitFlow pourrait ralentir le processus de dĂ©veloppement et le cycle de publication. En ce sens, GitFlow n’est pas une approche efficace pour les Ă©quipes qui souhaitent mettre en Ĺ“uvre l’intĂ©gration continue et le dĂ©ploiement continu.
Dans ce cas, un flux de travail beaucoup plus simple, tel que GitHub Flow, est recommandé.
GitHub Flow
GitHub Flow est une alternative plus simple Ă GitFlow, idĂ©ale pour les petites Ă©quipes qui n’ont pas besoin de gĂ©rer plusieurs versions.
Contrairement Ă GitFlow, ce modèle n’a pas de branches de release. Vous commencez avec la branche principale, puis les dĂ©veloppeurs crĂ©ent des branches de fonctionnalitĂ©s qui dĂ©coulent directement de la branche principale, pour isoler leur travail qui est ensuite fusionnĂ© dans la branche principale. La branche de fonctionnalitĂ© est ensuite supprimĂ©e.
L’idĂ©e principale de ce modèle est de maintenir le code principal dans un Ă©tat constant de dĂ©ploiement et donc de soutenir les processus d’intĂ©gration continue et de dĂ©ploiement continu.
Les avantages et les inconvénients de GitHub Flow
Github Flow se concentre sur les principes de la mĂ©thode Agile. Il s’agit donc d’une stratĂ©gie de branches rapide et rationalisĂ©e, avec des cycles de production courts et des releases frĂ©quentes.
Cette stratégie prévoit également des boucles de rétroaction rapides afin que les équipes puissent rapidement identifier les problèmes et les résoudre.
Comme il n’y a pas de branche de dĂ©veloppement, vous testez et automatisez les changements sur une seule branche, ce qui permet un dĂ©ploiement rapide et continu.
Cette stratégie est particulièrement adaptée aux petites équipes et aux applications web et elle est idéale lorsque vous devez maintenir une seule version de production.
Cette stratĂ©gie n’est donc pas adaptĂ©e Ă la gestion de plusieurs versions du code.
En outre, l’absence de branches de dĂ©veloppement rend cette stratĂ©gie plus vulnĂ©rable aux bugs et peut donc conduire Ă un code de production instable, particulièrement si les branches ne sont pas correctement testĂ©es avant d’ĂŞtre fusionnĂ©es avec la branche de release principale et si les corrections de bugs sont effectuĂ©es sur cette branche. Par consĂ©quent, la branche principale peut s’encombrer plus facilement puisqu’elle sert Ă la fois de branche de production et de branche de dĂ©veloppement.
Un autre inconvénient est que ce modèle est plus adapté aux petites équipes et donc, lorsque les équipes grandissent, des conflits de fusion peuvent se produire car tout le monde fusionne sur la même branche et il y a un manque de transparence. Ceci signifie que les développeurs ne peuvent pas voir sur quoi les autres développeurs travaillent.
GitLab Flow
GitLab Flow est une alternative plus simple à GitFlow qui combine le développement axé sur les fonctionnalités et les branches de fonctionnalités avec le repérage des incidents.
Avec GitFlow, les développeurs créent une branche de développement et en font la branche par défaut, tandis que GitLab Flow travaille immédiatement avec la branche principale.
GitLab Flow est idĂ©al si vous souhaitez maintenir plusieurs environnements et si vous prĂ©fĂ©rez disposer d’un environnement d’essai distinct de l’environnement de production. Ensuite, lorsque la branche principale est prĂŞte Ă ĂŞtre dĂ©ployĂ©e, vous pouvez la fusionner avec la branche de production et la publier.
Cette stratégie offre donc une réelle isolation entre les environnements, ce qui permet aux développeurs de maintenir plusieurs versions du logiciel dans des environnements différents.
Alors que GitHub Flow suppose que vous pouvez dĂ©ployer en production chaque fois que vous fusionnez une branche de fonctionnalitĂ©s avec la branche principale, GitLab Flow cherche Ă rĂ©soudre ce problème en permettant au code de passer par des environnements internes avant d’atteindre la production, comme le montre l’image ci-dessous.
Cette mĂ©thode convient donc aux situations oĂą vous ne contrĂ´lez pas le moment de la release, comme dans le cas d’une application iOS qui doit d’abord ĂŞtre validĂ©e par l’App Store ou lorsque vous avez des fenĂŞtres de dĂ©ploiement spĂ©cifiques.
Développement basé sur le tronc
Le développement basé sur le tronc est une stratégie de branches qui ne nécessite en fait aucune branche. Les développeurs intègrent leurs modifications dans un tronc partagé au moins une fois par jour. Ce tronc commun doit être prêt à être publié à tout moment.
L’idĂ©e principale derrière cette stratĂ©gie est que les dĂ©veloppeurs fassent des changements plus petits et plus frĂ©quemment, et donc l’objectif est de limiter les branches de longue durĂ©e et d’Ă©viter les conflits de fusion puisque tous les dĂ©veloppeurs travaillent sur la mĂŞme branche. En d’autres termes, les dĂ©veloppeurs s’engagent directement dans le tronc sans utiliser de branches.
Par consĂ©quent, le dĂ©veloppement basĂ© sur le tronc est un Ă©lĂ©ment clĂ© de l’intĂ©gration continue (CI) et du dĂ©ploiement continu (CD), car les modifications sont apportĂ©es plus frĂ©quemment au tronc, souvent plusieurs fois par jour (CI), ce qui permet de publier les fonctionnalitĂ©s beaucoup plus rapidement (CD).
Cette stratĂ©gie est souvent combinĂ©e avec les feature flags. Comme le tronc est toujours prĂŞt Ă ĂŞtre publiĂ©, les feature flags permettent de dĂ©coupler le dĂ©ploiement de la publication. Ainsi, toute modification qui n’est pas prĂŞte peut ĂŞtre enveloppĂ©e dans un feature flag et gardĂ©e cachĂ©e, tandis que les fonctionnalitĂ©s complètes peuvent ĂŞtre mises Ă disposition des utilisateurs finaux sans dĂ©lai.
Les avantages et les inconvénients du développement axé sur le tronc
Comme nous l’avons vu, le dĂ©veloppement axĂ© sur le tronc ouvre la voie Ă l’intĂ©gration continue car le tronc est constamment mis Ă jour.
Il amĂ©liore Ă©galement la collaboration, car les dĂ©veloppeurs ont une meilleure visibilitĂ© sur les modifications apportĂ©es par les autres dĂ©veloppeurs, Ă©tant donnĂ© que les modifications sont effectuĂ©es directement sur le tronc, sans qu’il soit nĂ©cessaire de crĂ©er des branches. Cette mĂ©thode est diffĂ©rente des autres mĂ©thodes de branches oĂą chaque dĂ©veloppeur travaille indĂ©pendamment dans sa propre branche et oĂą les modifications apportĂ©es Ă cette branche ne sont visibles qu’après avoir Ă©tĂ© fusionnĂ©es avec la branche principale.
Comme le développement axé sur le tronc ne nécessite pas de branches, cela élimine le stress des branches de longue durée et donc les conflits de fusion ou le fameux « enfer de la fusion », car les développeurs apportent de petites modifications beaucoup plus souvent. Cela facilite également la résolution des conflits éventuels.
Enfin, cette stratégie permet des releases plus rapides car le tronc commun est maintenu dans un état constant de release avec un flux continu de travail intégré dans le tronc, ce qui se traduit par une version plus stable.
Cependant, cette stratĂ©gie convient aux dĂ©veloppeurs plus expĂ©rimentĂ©s, car elle offre une grande autonomie que les dĂ©veloppeurs inexpĂ©rimentĂ©s pourraient trouver dĂ©courageante puisqu’ils interagissent directement avec le tronc commun. Par consĂ©quent, pour une Ă©quipe plus junior dont vous devez surveiller le travail de près, vous pouvez opter pour une stratĂ©gie de branches Git.
Lorsque l’on dĂ©bute, il est prĂ©fĂ©rable d’aller au plus simple et donc, dans un premier temps, le dĂ©veloppement GitHub Flow ou axĂ© sur le tronc peut s’avĂ©rer le plus adaptĂ©. Ils sont Ă©galement idĂ©aux pour les petites Ă©quipes qui n’ont besoin que d’une seule version d’un projet Ă maintenir.
GitFlow est idĂ©al pour les projets open-source qui nĂ©cessitent un contrĂ´le d’accès strict aux modifications. C’est d’autant plus important que les projets open-source permettent Ă tout un chacun de contribuer et qu’avec GitFlow, vous pouvez vĂ©rifier ce qui est introduit dans le code source.
Cependant, GitFlow, comme mentionnĂ© prĂ©cĂ©demment, n’est pas adaptĂ© Ă la mise en Ĺ“uvre d’un environnement DevOps. Dans ce cas, les autres stratĂ©gies discutĂ©es conviennent mieux Ă un processus DevOps agile et au soutien de votre pipeline de CI-CD.
Le tableau suivant résume les stratégies discutées dans cet article et indique quelle stratégie est appropriée dans quel contexte :
Type de produit et méthode de diffusion Taille de l’équipe Maturité de la collaboration Stratégie de branches principale applicable Tout Petites équipes Haute Développement basé sur le tronc Produits permettant un déploiement et une mise à jour continus, tels que les produits SaaS. Moyenne Moyenne GitHub-Flow et développement basé sur le tronc Produits avec une fenêtre de release définie et une cadence de publication périodique, tels que les applications iOS. Moyenne Moyenne Git-Flow et GitLab-Flow avec branche de release Produits exigeants en termes de qualité et supportant un déploiement et des releases en continu, tels que les plateformes produits de base. Moyenne Moyenne GitLab-Flow Produits exigeants en termes de qualité et ayant un long cycle de maintenance pour les versions publiées, tels que les plateformes produits de base 2B. Grande Moyenne Git-Flow
En rĂ©sumĂ©, la stratĂ©gie parfaite n’existe pas. La stratĂ©gie que vous choisirez dĂ©pendra de votre Ă©quipe ainsi que de la nature et de la complexitĂ© de votre projet et devra donc ĂŞtre Ă©valuĂ©e au cas par cas.
Il est Ă©galement possible de commencer par une stratĂ©gie et de l’adapter au fil du temps en fonction de vos besoins. Il va sans dire que, quelle que soit la stratĂ©gie choisie, elle doit viser Ă accroĂ®tre la productivitĂ© de votre Ă©quipe en lui donnant une stratĂ©gie claire et cohĂ©rente pour organiser son travail.