Article

15min lecture

Quelles sont les meilleures stratégies de gestion de branches avec Git ?

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.

Author: Vincent Driessen
Article de blog original
License: Creative Commons BY-SA

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.

Comment choisir la meilleure stratégie de branches pour votre équipe ?

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 diffusionTaille de l’équipe



Maturité de la collaboration
Stratégie de branches principale applicable
ToutPetites équipesHauteDéveloppement basé sur le tronc
Produits permettant un déploiement et une mise à jour continus, tels que les produits SaaS.MoyenneMoyenneGitHub-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.MoyenneMoyenneGit-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.MoyenneMoyenneGitLab-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.GrandeMoyenneGit-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.

Abonnez-vous à
notre Newsletter

bloc Newsletter FR

AB Tasty traite et stocke vos données personnelles pour vous envoyer des communications tel que détaillé dans notre politique de confidentialité ici.

Article

5min lecture

Le futur de la personnalisation digitale : EmotionsAI d’AB Tasty

Chez AB Tasty, nous comprenons à quel point il est important de pouvoir personnaliser votre contenu en fonction de votre audience. Nous savons également que jusqu’à 80 % des consommateurs sont plus susceptibles de finaliser un achat en ligne avec des marques qui proposent des expériences client personnalisées.

Nous avons travaillé sans relâche pour permettre aux entreprises de personnaliser dynamiquement le contenu de leur site web, leurs recommandations produits et leurs offres promotionnelles, le tout en fonction des préférences, du comportement et des données démographiques de chaque utilisateur.

Cependant, nous constatons que les stratégies de personnalisation restent difficiles à mettre en place et donnent souvent le sentiment aux utilisateurs de ne pas être compris par les marques. Avec pour objectif de proposer une expérience fluide et optimisée pour chaque visiteur, la démarche de personnalisation doit se baser sur les besoins émotionnels de chacun afin de créer l’engagement. Or, ces besoins sont particulièrement difficiles à identifier.

Le rôle des émotions

Les marques doivent comprendre pourquoi le visiteur prend la décision d’aller plus loin dans le parcours d’achat afin de répondre au mieux à ses attentes. Or, il est prouvé que la majorité de ces décisions sont émotionnelles plutôt que rationnelles. Richard Zaltman, professeur à la Harvard Business School, indique même que 95% de celles-ci sont non conscientisées, basées sur l’intuition et l’émotion plutôt qu’issues d’une approche consciente et rationnelle.

Ainsi, les émotions ont un impact majeur sur l’ensemble du parcours d’achat. Or chaque visiteur est unique et donc stimulé par différentes expériences. Certains adorent les parcours où toutes les informations et options sont proposées, alors que d’autres vont préférer des parcours minimalistes, avec des photos plutôt que des mots. Chaque visiteur a ses propres besoins émotionnels, qu’il faut réussir à identifier, comprendre et finalement combler pour pouvoir concevoir et proposer une expérience qui convertit.

Alors, comment identifier les besoins émotionnels de chaque visiteur et mettre en place des expériences digitales optimales pour chacun ? Comment prendre des décisions data-driven pour répondre aux besoins émotionnels de vos visiteurs ?

Finalement, comment optimiser l’expérience digitale de façon pertinente en fonction des désirs distincts de chaque personne ?

La prochaine étape de la personnalisation digitale : EmotionsAI d’AB Tasty

Des centaines de modèles comportementaux révèlent la personnalité de vos acheteurs et alimentent notre algorithme EmotionsAI.

Chez AB Tasty, nous aimons repousser les limites des expériences digitales et c’est pourquoi nous sommes ravis de vous présenter notre nouvelle acquisition : EmotionsAI. Avec cet outil, vous pouvez expérimenter des messages uniques et personnalisés pour chaque type de visiteur, plonger dans les données pour comprendre leurs besoins, mener des tests pour identifier les messages efficaces ou encore construire des parcours personnalisés ciblant des besoins émotionnels spécifiques.

Connue précédemment sous le nom de Dotaki, cette technologie est basée sur un mélange unique de science comportementale et d’analyse de données. Elle repose sur des années de modélisation comportementale, de cartographie du parcours client et d’Intelligence Artificielle, combinées à l’analyse des interactions en temps réel des internautes sur votre site web.

Les marques utilisent déjà EmotionsAI et AB Tasty pour :

  • Comprendre les besoins émotionnels de leur audience afin de renforcer leur roadmap d’optimisation de l’expérience avec des messages, des designs et des CTA efficaces qui captivent leurs visiteurs.
  • Obtenir davantage de variations gagnantes en approfondissant ce qui fonctionne et pour quel besoin émotionnel grâce à l’analyse des données.
  • Personnaliser leurs campagnes avec un ciblage en fonction des besoins émotionnels dans l’outil AB Tasty Audience Builder.

Segmentation client par besoin émotionnel

EmotionsAI peut vous aider à comprendre quel type de visiteur se trouve sur votre site. Par exemple, si un visiteur est détecté comme ayant des besoins de compétition, il réagira fortement à des preuves sociales ou à la mention de stocks limités sur les produits. Si un visiteur est considéré comme ayant des besoins de sécurité, il recherchera un système de paiement clair et sécurisé, avec des réassurances tout au long du processus. Les visiteurs pragmatiques, quant à eux, recherchent « l’immédiateté » et souhaitent emprunter le chemin le plus rapide pour effectuer leur achat, avec le moins d’obstacles possible.

Résultats

Une fois que vous êtes capable de segmenter les visiteurs grâce à EmotionsAI, vous pouvez identifier instantanément quand une variation répond aux besoins émotionnels d’une partie de l’audience. 

L’impact sur le taux de succès des tests est impressionnant : avec EmotionsAI, 60% des variations de test montrent un impact business positif, par rapport à 10% sans EmotionsAI. Deplus, les campagnes de personnalisation utilisant EmotionsAI ont connu des augmentations de revenus allant de 5% à 10%. Cela ouvre la voie avec une facilité déconcertante à la mise en place de stratégies de personnalisation de l’expérience client ciblant les visiteurs sur le critère le plus pertinent possible : l’émotionnel.

Gardez une longueur d’avance avec la prochaine étape de l’optimisation de l’expérience en maîtrisant la personnalisation émotionnelle grâce à EmotionsAI. 

EmotionsAI est un outil AB Tasty de segmentation alimenté par l’IA, permettant une meilleure personnalisation et des taux de conversion plus élevés.