Discussion :

[ulspider]

Bonsoir,

j'ai besoin d'aide pour faciliter la gestion des différentes branches "version" correspondant à nos différentes versions projets dans mon équipe. Nous traitons au sein de mon équipe (25 développeurs environ) une branche de correction production (que nous appellerons version-n/develop) et 2 versions de développement pour les échéances suivantes que nous nommerons version-n-plus-1/develop et version-n-plus-2/develop. Les branches version-n-plus-1/develop et version-n-plus-2/develop peuvent vivre plusieurs mois car nous ne mettons en production des versions majeures que tous les 6 mois et la production est patchée toutes les 2 semaines à partir de la branche version-n/develop.

Nous rencontrons de grosses difficultés sur les phases de reports de code de la branche maintenance vers les branches projets N+1. Après chaque installation en production, nous reportons les tags associées sur la branche N+1. Pour les reports N+1 vers N+2, nous le faisons en début de sprint de la version N+2 toutes les 3 semaines afin d'éviter une divergence trop difficile à gérer, notamment avec les phases de refactorisation que nous réalisons sur les branches N+1 et N+2.

La procédure que nous appliquons pour les reports N vers N+1 (la même entre N+1 et N+2)

• Récupération de la branche version-n-plus-1/develop (git pull)
• Création d'une branche report version-n-plus-1/report/merge-tag-version-n-XXX (git create branch)
• Switch sur la branche créée (git checkout)
• Merge du tag production (git merge tag-version-n-XXX)
• On résout les conflits
• On lance les TU
• On réalise quelques tests manuels
• On fait un pull rebase de la branche version-n-plus-1/develop pour récupérer les éventuels commit produient entre temps.
• On fait un rebase de version-n-plus-1/develop depuis notre branche de report version-n-plus-1/report/merge-tag-version-n-XXX, et là on galère !!! (mot très faible...)
• On merge ensuite sur version-n-plus-1/develop la branche version-n-plus-1/report/merge-tag-version-n-XXX.
• On envoit sur le serveur distant (git push)

Notre procédure est-elle correcte ? Doit-on vraiment faire un rebase à la fin de nos tests après le merge sur la branche de report ? Si ce n'est pas nécessaire, comment devons-nous gérer le cas où il y a eu un commit entre temps sur version-n-plus-1/develop ? En ne faisant pas de rebase, aura-t-on un historique des commits pourri ? Des idées ?

Merci par avance ^^

[Obsidian]

Bonjour,

Je suis loin d'être un expert des workflows des SCM même si j'utilise Git au quotidien mais effectivement, présenté comme tu le fais, vous avez l'air de vous donner beaucoup de mal.

En premier lieu, sur quel nœud sont déclarées les branches « n+1/dev » et « n+2/dev » ? C'est important pour savoir dans quelles proportions ces versions n+1 et n+2 restent des évolutions en continu de la version n ou forment des forks distincts. Parce qu'effectivement, si vous déclarez trois branches dès le départ, qu'elles vivent leur vie propre et que vous rappelez au dernier moment toutes les modifications appliquées sur n vers n+1 et n+2, ça risque de rendre les choses compliquées.

Ensuite, pourquoi avez-vous besoin d'une branche n+2 ? (c'est une vraie question) Comment décidez-vous de ce qui doit faire partie de n+1 et de ce qui ne sortira qu'avec n+2 ?

Par ailleurs, il est curieux que vous ayez besoin de reporter beaucoup de tags. Normalement, vous ne devriez avoir à en déplacer qu'une poignée, ceux-là même qui représentent des états particuliers, par exemple la version actuellement poussée sur un serveur de test ou autres mais en temps normal, ils sont justement faits pour qualifier une version donnée et, donc, ne jamais avoir à bouger.


Côté workflow proprement dit, il y a généralement une seule grande ligne de développement à un moment donné, même si plusieurs sous-branches sont définies tout autour et viennent s'y fondre, comme les affluents d'un fleuve. Les différentes contributions (évolutions ou correctifs) y sont d'abord intégrés puis sont rétro-portées aux versions stables antérieures, justement pour éviter de risquer d'être confronté dans les versions à sortir aux mêmes bugs que ce que l'on vient de corriger dans les plus anciennes.

Dans le processus de développement du noyau Linux, par exemple, dès qu'une version « majeure » (les deux premiers numéros, avec le troisième à zéro, ou absent) est publiée, cela annonce simultanément (le jour même) l'ouverture de la fenêtre d'intégration pour la prochaine version majeure, fenêtre qui dure deux semaines, suivi de sept à huit semaines de stabilisation, pendant lesquelles sont publiées les fameuses release candidates « -rcn ». Bien sûr, ces patches doivent être dûment mûris avant d'arriver jusque là et il le sont en fait sur une arborescence distincte appelée linux-next et qui est une agrégation plus ou moins automatique des différentes branches de développement des équipes en charge de chaque sous-système.

Toujours est-il que Linus publie en fait à chaque fois une version majeure qui fait suite à la version majeure précédente (la prochaine à sortir sera le noyau 4.16) et que parallèlement, chacune de ses versions vit une vie propre en tant que branche stable, lesquelles sont maintenues par une équipe distincte. Et les conditions pour y soumettre un patch impliquent entre autres que celui-ci doit être un correctif (pas une nouvelle fonctionnalité), qui doit être concis, ne corriger qu'une seule chose, que ce soit réellement ennuyeux pour l'utilisateur (sinon on considère la chose comme gravée dans le marbre pour cette version) et, surtout, que ce patch (ou un équivalent) ait déjà été intégré dans la branche principale.

On comprend que suivant ce modèle, c'est toujours la branche principale qui concentre l'effort de développement et c'est qu'une fois qu'une modification est appliquée et testée proprement de ce côté qu'on envisage éventuellement de la rétro-porter.

Notre procédure est-elle correcte ? Doit-on vraiment faire un rebase à la fin de nos tests après le merge sur la branche de report ? Si ce n'est pas nécessaire, comment devons-nous gérer le cas où il y a eu un commit entre temps sur version-n-plus-1/develop ? En ne faisant pas de rebase, aura-t-on un historique des commits pourri ? Des idées ?

Si c'est pour appliquer des changesets au cas par cas depuis une branche notoirement distincte, tu peux utiliser git cherry et git cherry-pick, d'où l'intérêt de bien cuisiner ses commits et de rassembler ses contributions par thème, et pas ajouter tous les fichiers modifiés dans un seul gros commit à intervalles réguliers. Mais normalement, en effet, tu ne devrais pas en avoir besoin.

[Marco46]

On fait un rebase de version-n-plus-1/develop depuis notre branche de report version-n-plus-1/report/merge-tag-version-n-XXX, et là on galère !!! (mot très faible...)

J'ai envie de dire normal, puisque vous n'êtes pas censés réécrire l'historique d'une branche publique. Vous devez obtenir de gros problèmes de divergences d'historique.

Ensuite, pourquoi avez-vous besoin d'une branche n+2 ? (c'est une vraie question) Comment décidez-vous de ce qui doit faire partie de n+1 et de ce qui ne sortira qu'avec n+2 ?

C'est probablement ici que vous avez le plus gros potentiel de gain dans votre workflow.

Vous devriez regarder du côté du trunk based development et à minima du côté du feature toggle.

L'idée générale c'est d'avoir une seule branche d'intégration des développements et de faire porter la complexité des features branchs par des booléens dans votre code source. Il est important de noter que cela augmente sensiblement la complexité et donc la difficulté à tester efficacement l'application. Ces toggles doivent donc être temporaires et disparaître dès que possible, il ne doit pas s'agir de configuration de fonctionnalité durable dans le temps.

Une autre ressource intéressante c'est cette présentation de la Société Générale à Devoxx 2016 :

C'est en plein dans ta problématique je pense.

[ulspider]

Bonjour,
En premier lieu, sur quel nœud sont déclarées les branches « n+1/dev » et « n+2/dev » ? C'est important pour savoir dans quelles proportions ces versions n+1 et n+2 restent des évolutions en continu de la version n ou forment des forks distincts. Parce qu'effectivement, si vous déclarez trois branches dès le départ, qu'elles vivent leur vie propre et que vous rappelez au dernier moment toutes les modifications appliquées sur n vers n+1 et n+2, ça risque de rendre les choses compliquées.

La version n+1 est tirée après la mise en production de la version n en générale (voir un peu avant), version n qui passe en maintenance jusqu'à ce que la version n+1 soit mis en production, en générale 6 mois plus tard.

Bonjour,
Ensuite, pourquoi avez-vous besoin d'une branche n+2 ? (c'est une vraie question) Comment décidez-vous de ce qui doit faire partie de n+1 et de ce qui ne sortira qu'avec n+2 ?

En fait les versions sont en générale très grosses et les dates de mise en production sont connues à l'avance, imposées et gravées dans le marbre. Afin d'être présent au rendez-vous, il est assez fréquent que nous devions commencer bien en avance les développements, avec potentiellement une version n+1 en parallèle déjà en cours de développement, la n+2 ayant été anticipée afin d'avoir le maximum de contenu fonctionnel.

Par ailleurs, il est curieux que vous ayez besoin de reporter beaucoup de tags. Normalement, vous ne devriez avoir à en déplacer qu'une poignée, ceux-là même qui représentent des états particuliers, par exemple la version actuellement poussée sur un serveur de test ou autres mais en temps normal, ils sont justement faits pour qualifier une version donnée et, donc, ne jamais avoir à bouger.

Je dis beaucoup de tags car ce n'est pas une application mais des applications que nous gérons, nous sommes en micro-services. Nous reportons les versions (i.e tag des micro services) qu'après chaque mep, et uniquement des micro-services qui ont évolué en phase de maintenance.

Côté workflow proprement dit, il y a généralement une seule grande ligne de développement à un moment donné, même si plusieurs sous-branches sont définies tout autour et viennent s'y fondre, comme les affluents d'un fleuve. Les différentes contributions (évolutions ou correctifs) y sont d'abord intégrés puis sont rétro-portées aux versions stables antérieures, justement pour éviter de risquer d'être confronté dans les versions à sortir aux mêmes bugs que ce que l'on vient de corriger dans les plus anciennes.

C'est cette partie que j'ai du mal à mettre en place en fait avec Git.

J'ai envie de dire normal, puisque vous n'êtes pas censés réécrire l'historique d'une branche publique. Vous devez obtenir de gros problèmes de divergences d'historique.

Et donc que devons nous faire ? Qu'elle est la bonne pratique ?

[Marco46]

Et donc que devons nous faire ? Qu'elle est la bonne pratique ?

La bonne pratique c'est de ne pas rebaser une branche qui a été publiée (hors de toute question de workflow). Une branche publiée c'est une branche qui a été poussée sur un repo central et qui a donc pu être tirée par un autre développeur. Rebaser signifie changer la base de la branche (le commit parent initial) et cela se traduit par une regénération de tous les commits de la branche et donc de la somme de contrôle (le SHA1). Donc si un développeur A a tiré une branche qui est ensuite rebasée par un développeur B, le développeur B sera contraint de faire un git push --force pour écraser la branche sur le repo central, et le développeur A aura une erreur de divergence d'historique sur sa version locale de la branche lorsqu'il voudra pull. Et il va devoir effectuer des opérations pénibles pour retomber sur ses pieds.

Donc pas de rebase de branche publique, cela revient à réécrire l'histoire, c'est à faire seulement lorsque cette histoire est encore privée pour nettoyer l'histoire avant de la pousser aux autres.

Je dis beaucoup de tags car ce n'est pas une application mais des applications que nous gérons, nous sommes en micro-services. Nous reportons les versions (i.e tag des micro services) qu'après chaque mep, et uniquement des micro-services qui ont évolué en phase de maintenance.

Crucial comme info pour comprendre ton problème !

Donc vous êtes en monorepo, et vous avez plusieurs livrables (un par microservice).

Cela signifie qu'un tag (qui est simplement un alias d'un commit) n'identifie pas une version d'un service. Il identifie une version de la totalité des services. Un commit peut parfaitement contenir des modifications de différentes natures sur plusieurs services. Sur un même commit tu peux avoir un breaking change sur un service A, un ajout de fonctionnalité sur un service B, et un hotfix sur un service C. Tu ne peux donc pas utiliser les tags git pour gérer le versioning opérationnel de tes microservices. Il en faut un deuxième !

Si tu es en microservice, chaque microservice doit avoir son propre numéro de version en autonomie parce que chaque microservice est un livrable à part et autonome.

Pour t'aider plus avant, il faudrait donc confirmer qu'on comprend bien ta situation :
- monorepo
- microservice
- un système de versionning unique pour tous les microservices
- 2 lignes de développement (+ les hotfix de prod)
- des cycles de MEP avec ajout fonctionnel de 6 mois (pour quelle raison d'ailleurs ?)

Est-ce que j'ai bien compris ?

[Obsidian]

Bonsoir,

La version n+1 est tirée après la mise en production de la version n en générale (voir un peu avant), version n qui passe en maintenance jusqu'à ce que la version n+1 soit mis en production, en générale 6 mois plus tard.

En fait les versions sont en générale très grosses et les dates de mise en production sont connues à l'avance, imposées et gravées dans le marbre. Afin d'être présent au rendez-vous, il est assez fréquent que nous devions commencer bien en avance les développements, avec potentiellement une version n+1 en parallèle déjà en cours de développement, la n+2 ayant été anticipée afin d'avoir le maximum de contenu fonctionnel.

Si vous publiez à dates fixes (ce qui ce conçoit tout-à-fait), je peux comprendre que vous ayez besoin d'une branche de développement « longue durée » pour commencer à travailler sur deux choses qui ne peuvent pas être bouclées en six mois.

Malgré tout, vous devez (selon moi) avoir une branche principale qui serve de référence, parce que en l'état, il semblerait que vous gériez vos versions comme des forks : des produits distincts qui, à chaque fois, auraient dérivé d'un point bien identifié mais auraient vécu leur vie propre chacun de leur côté et qu'au moment de publier, vous tentiez de re-fusionniez le tout. L'intégration des branches de développement pendant le sprint final n'est déjà pas une chose très agréable en temps normal (sauf à la limite pour un mainteneur, et encore, c'est généralement un sacerdoce) mais là, ce doit être un vrai casse-tête.

Après, pour concilier le développement de n+1 et la maintenance de n, il y a deux grandes approches : soit vous suivez le modèle utilisé par Linux, à savoir « on développe sur la branche de développement, et on rétro-porte éventuellement ce qui doit l'être sur la branche stable », soit vous intégrez régulièrement l'état de la branche stable sur la branche de développement, avant de re-fusionner celle-ci à la fin, comme ceci (source) :



… et vous le faites autant sur n+1 que sur n+2 à chaque fois que la branche principale change (ou au moins à intervalles réguliers). De cette façon, c'est sur la branche de développement que les conflits sont résolus et pas l'inverse, et ils le sont en temps réel. La fusion finale se passe alors sans douleur et la branche finalisée disparaît d'elle-même sans que vous n'ayez à rebaser quoi que ce soit.

[ulspider]

La bonne pratique c'est de ne pas rebaser une branche qui a été publiée (hors de toute question de workflow). Une branche publiée c'est une branche qui a été poussée sur un repo central et qui a donc pu être tirée par un autre développeur. Rebaser signifie changer la base de la branche (le commit parent initial) et cela se traduit par une regénération de tous les commits de la branche et donc de la somme de contrôle (le SHA1). Donc si un développeur A a tiré une branche qui est ensuite rebasée par un développeur B, le développeur B sera contraint de faire un git push --force pour écraser la branche sur le repo central, et le développeur A aura une erreur de divergence d'historique sur sa version locale de la branche lorsqu'il voudra pull. Et il va devoir effectuer des opérations pénibles pour retomber sur ses pieds.

Donc pas de rebase de branche publique, cela revient à réécrire l'histoire, c'est à faire seulement lorsque cette histoire est encore privée pour nettoyer l'histoire avant de la pousser aux autres.

Cela m'éclaire beaucoup, merci ! Donc le développeur qui traite les reports sur la branche version-n-plus-1/report/merge-tag-version-n-XXX réalise un merge du tag tag-version-n-XXX, fait ses tests et enfin merge sur la branche version-n-plus-1/develop (via gitlab) sans faire de rebase. Pour les développeurs qui ont tiré des features branches d'une version antérieure de version-n-plus-1/develop, ils doivent après le merge du report faire un rebase en local, puis pousser leur branche pour merge (avec revue de code) par Gitlab ? Ils ne rencontreront pas de soucis lors de leurs rebase ?

Pour t'aider plus avant, il faudrait donc confirmer qu'on comprend bien ta situation :
- monorepo
- microservice
- un système de versionning unique pour tous les microservices
- 2 lignes de développement (+ les hotfix de prod)
- des cycles de MEP avec ajout fonctionnel de 6 mois (pour quelle raison d'ailleurs ?)

Est-ce que j'ai bien compris ?

- multirepo, un par micro-service, nommage des branches échéances de la même manière sur tous les repos Git.
- 2 lignes de développement projets
- une ligne de développement maintenance, des corrections de production qui peuvent attendre 2/3 semaines (pas de blocage en production ou solution de contournement existante) et des évolutions éligibles à la maintenance (évolutions sans adhérence avec des applications backend)
- une ligne de développement d'urgence pour les hotfix, si un rayon cosmique arrive sur la production. Là c'est branle bas de combat :-P
- des cycles de MEP avec ajout fonctionnel de 6 mois (pour quelle raison d'ailleurs ?) => Nous sommes tributaires d'autres applications qui elles sont déployées en agence via un cycle assez complexe (genre un an de recette). Bref, ceux sont les autres qui nous imposent, on s'insère dans un wagon de train mais on ne maitrise pas le train :-P

Si tu es en microservice, chaque microservice doit avoir son propre numéro de version en autonomie parce que chaque microservice est un livrable à part et autonome.

ça c'est pas forcément évident. Je suis d'accord avec toi (c'est ce que nous faisons) mais on s'est pris un audit et l'audit a remonté qu'il pouvaient être intéressant d'avoir un repo unique pour tout nos micro-services afin d'avoir une sorte d'image unique à chaque fois que l'on tag (livre) les composants en recette. Après ça soulève d'autres problèmes, un build unique qui prend du temps sous Jenkins, mise en place de build en delta pour gagner en performance... Bref, dans les 2 cas ce n'est pas simple. Ton avis là dessus ?

Pièce jointe 359058

… et vous le faites autant sur n+1 que sur n+2 à chaque fois que la branche principale change (ou au moins à intervalles réguliers). De cette façon, c'est sur la branche de développement que les conflits sont résolus et pas l'inverse, et ils le sont en temps réel. La fusion finale se passe alors sans douleur et la branche finalisée disparaît d'elle-même sans que vous n'ayez à rebaser quoi que ce soit.

Merci aussi, ça m'a bien éclairé.

Je pense que la procédure sera donc :

• Récupération de la branche version-n-plus-1/develop (git pull)
• Création d'une branche report version-n-plus-1/report/merge-tag-version-n-XXX (git create branch)
• Switch sur la branche créée (git checkout)
• Merge du tag production (git merge tag-version-n-XXX)
• On résout les conflits
• On lance les TU
• On réalise quelques tests manuels
• On envoie sur le serveur distant la brande report (git push)
• On merge ensuite sur version-n-plus-1/develop la branche version-n-plus-1/report/merge-tag-version-n-XXX via Gitlab (revue de code)

Et on fait cela pour chaque repo micro-service, toutes les 3 semaines en début de sprint. Je pense également que l'on va faire plutôt un git merge --squash afin d'avoir un seul commit au final pour les opérations de merge. Voys en pensez quoi ?

[Marco46]

Cela m'éclaire beaucoup, merci ! Donc le développeur qui traite les reports sur la branche version-n-plus-1/report/merge-tag-version-n-XXX réalise un merge du tag tag-version-n-XXX, fait ses tests et enfin merge sur la branche version-n-plus-1/develop (via gitlab) sans faire de rebase.

Perso je supprimerais la branche version-n-plus-1/report/merge-tag-version-n-XXX et je mergerais version-n dans version-n-plus-1. Le parent de n+1 c'est forcément n. Donc c'est n qui doit se déverser dans n+1. La branche de report est inutile. Tu fais une merge request de n vers n+1, si il y a des conflits, un dev doit tirer la branche sur sa machine, résoudre les conflits, pousser la branche directement sur le repo puis la MR peut être validée.

Pour les hotfix de prod c'est la même idée. Leurs branches partent forcément des tags déployés. Donc les hotfix doivent être reversés vers la n. Une fois dans n, ils seront mécaniquement renvoyés vers n+1 lorsque n+1 récupérera n.

Sur mon projet actuel il y a plusieurs projets backends J2EE avec archi monolithiques et un front unique. On a plusieurs branches d'intégration des développements ce qui correspond à peu près à ton cas de figure mais en plus complexe. On a aussi plusieurs équipes différentes qui travaillent, bref c'est un peu compliqué. On fonctionne comme ça. En revanche les équipes qui travaillent à n+1 mergent l'état de la branche d'intégration des devs de n très régulièrement (genre toutes les semaines) pour éviter un conflit de la mort qui serait impossible à réaliser et qui tuerait le projet (ça peut très bien arriver si tu attends trop pour reporter les modifs !).

Quand n arrivera en prod, n+1 deviendra n, et une nouvelle n+1 pourra voir le jour.

Après selon les échéances des versions, il est possible d'avoir plusieurs n+1 qui partent de n au lieu d'un branchage en escalier mais là c'est vraiment la loose. C'est à peu près comme sortir tout nu tout mouillé en hiver, ça s'appelle chercher les problèmes !

Tout ce fonctionnement est vraiment bordélique, la plupart des boites qui ont ce genre de fonctionnement finissent par faire du trunk based dev, avec une seule branche d'intégration des devs et du feature toggle pour activer les features quand ils veulent les ouvrir aux utilisateurs.

Pour les développeurs qui ont tiré des features branches d'une version antérieure de version-n-plus-1/develop, ils doivent après le merge du report faire un rebase en local, puis pousser leur branche pour merge (avec revue de code) par Gitlab ?
Ils ne rencontreront pas de soucis lors de leurs rebase ?

Si tu ne réécris jamais l'historique, tu ne peux pas avoir de problème. Tu peux avoir des conflits à gérer comme lors d'un merge mais tu n'auras plus de divergences d'historique.

De toutes manières, il faut toujours rebaser sa branche de feature locale avec la branche parente avant de proposer une merge/pull request.

ça c'est pas forcément évident. Je suis d'accord avec toi (c'est ce que nous faisons) mais on s'est pris un audit et l'audit a remonté qu'il pouvaient être intéressant d'avoir un repo unique pour tout nos micro-services afin d'avoir une sorte d'image unique à chaque fois que l'on tag (livre) les composants en recette. Après ça soulève d'autres problèmes, un build unique qui prend du temps sous Jenkins, mise en place de build en delta pour gagner en performance... Bref, dans les 2 cas ce n'est pas simple. Ton avis là dessus ?

Mon avis ne sera pas pertinent dans le sens où j'ai jamais fait autre chose que du multi repo en archi monolithique. Donc j'ai pas de retour d'expérience à proposer. Ce qui est important c'est la cohérence d'ensemble et je trouve que utiliser un tag unique sur une collection de micro-services c'est incohérent. Le micro-service est le monorepo c'est super bien adapté à des équipes très larges avec beaucoup de features différentes et la nécessité d'avoir un temps de boot lors des MEP qui soit rapide. Bref c'est super bien adapté à du web avec des MEP très fréquentes, voire même plusieurs fois par jour. C'est ce que font tous les gros acteurs c'est pour ça que c'est à la mode et que le tooling autour se développe. Pour un cycle de vie de 2 MEP par an je suis beaucoup moins convaincu de l'utilité.

Je pense que la procédure sera donc :

[...]

Et on fait cela pour chaque repo micro-service, toutes les 3 semaines en début de sprint.

Mais vous avez des évols / hotfix sur chaque repo à chaque fois ?

[ulspider]

Perso je supprimerais la branche version-n-plus-1/report/merge-tag-version-n-XXX et je mergerais version-n dans version-n-plus-1. Le parent de n+1 c'est forcément n. Donc c'est n qui doit se déverser dans n+1. La branche de report est inutile. Tu fais une merge request de n vers n+1, si il y a des conflits, un dev doit tirer la branche sur sa machine, résoudre les conflits, pousser la branche directement sur le repo puis la MR peut être validée.

Nous utilisons les tags car il se peut que sur la branche n il y ait du code pas encore très stable. L’intérêt de reporter les tags c'est qu'une équipe de recette est intervenue et à valider le périmètre à livrer en production. J'hésite à faire ce que tu proposes mais c'est une bonne idée.

Pour les hotfix de prod c'est la même idée. Leurs branches partent forcément des tags déployés. Donc les hotfix doivent être reversés vers la n. Une fois dans n, ils seront mécaniquement renvoyés vers n+1 lorsque n+1 récupérera n.

Nous faisons exactement cela

Sur mon projet actuel il y a plusieurs projets backends J2EE avec archi monolithiques et un front unique. On a plusieurs branches d'intégration des développements ce qui correspond à peu près à ton cas de figure mais en plus complexe. On a aussi plusieurs équipes différentes qui travaillent, bref c'est un peu compliqué. On fonctionne comme ça. En revanche les équipes qui travaillent à n+1 mergent l'état de la branche d'intégration des devs de n très régulièrement (genre toutes les semaines) pour éviter un conflit de la mort qui serait impossible à réaliser et qui tuerait le projet (ça peut très bien arriver si tu attends trop pour reporter les modifs !).

Toutes les semaines, j'ai du mal à le faire appliquer, les développeurs râlent déjà avec les reports toutes les 3 semaines xD. Une fois en début de sprint, ça me semble un bon compromis.

Si tu ne réécris jamais l'historique, tu ne peux pas avoir de problème. Tu peux avoir des conflits à gérer comme lors d'un merge mais tu n'auras plus de divergences d'historique.

Ok je prends note. Dans le cas où il y a des conflits sur la MR de report, un développeur la récupère en local et résout les conflits. Si entre temps la branche N+1 avance parce qu'un autre développeur a mergé, on est bien d'accord, le premier ne fait pas de rebase sur sa branche locale de résolution des conflits du merge ? Dois-je bloquer la branche N+1 (i.e dire aux développeurs de ne pas merger les features en attente) pendant la phase résolution des conflits de la MR de report ?

Mon avis ne sera pas pertinent dans le sens où j'ai jamais fait autre chose que du multi repo en archi monolithique. Donc j'ai pas de retour d'expérience à proposer. Ce qui est important c'est la cohérence d'ensemble et je trouve que utiliser un tag unique sur une collection de micro-services c'est incohérent. Le micro-service est le monorepo c'est super bien adapté à des équipes très larges avec beaucoup de features différentes et la nécessité d'avoir un temps de boot lors des MEP qui soit rapide. Bref c'est super bien adapté à du web avec des MEP très fréquentes, voire même plusieurs fois par jour. C'est ce que font tous les gros acteurs c'est pour ça que c'est à la mode et que le tooling autour se développe. Pour un cycle de vie de 2 MEP par an je suis beaucoup moins convaincu de l'utilité.

Oui mais on nous a un peu forcé la main à mettre en place une architecture micro-service sans tenir compte des autres problématiques : DevOps inexistant chez nous, livraison par d'autres équipes à la main, recette peu automatisée à l'époque... ça commence à changer mais c'est très long...

Mais vous avez des évols / hotfix sur chaque repo à chaque fois ?

Non pas forcément, disons que le problème touche surtout 2 repo, qui sont assez gros.

[Marco46]

Nous utilisons les tags car il se peut que sur la branche n il y ait du code pas encore très stable. L’intérêt de reporter les tags c'est qu'une équipe de recette est intervenue et à valider le périmètre à livrer en production. J'hésite à faire ce que tu proposes mais c'est une bonne idée.

Je comprends, ça c'est un problème quand la politique de test est mauvaise ce qui est le cas dans beaucoup d'équipes (je n'y échappe pas rassure toi, je n'ai malheureusement pas toutes les cartes en main dans mon taf, loin de là). L'idée c'est de dire qu'une feature branch qui ne passe pas les tests (automatiques) ne doit pas être mergée. Et ces tests automatisés doivent avoir suffisamment de couverture technique et fonctionnelle (de pertinence quoi) pour être considérés comme une assurance suffisamment fiable et significative. En gros il peut rester des problèmes qui seront démêles plus tard par la QA, mais ça reste un reliquat marginal qui est acceptable. Donc on peut se permettre de merger régulièrement ce n'est pas trop grave.

Si vous en êtes à un point d'instabilité dans votre code que vous avez besoin d'une période de QA manuelle longue pour vous assurer que le service minimum est rendu, alors c'est que vous êtes au bord du gouffre. Tous les voyants sur la qualité devraient être au rouge. Le danger étant de rentrer dans un cycle où un fix a plus de chance de générer de nouveaux bugs et des régressions que le fix qu'il assure. Dans ce cas de figure c'est la capacité à délivrer du nouveau contenu qui est en danger. De nombreux produits et services ont cessé d'exister du fait de ce problème entraînant parfois des entreprises entières avec elles dans la tombe.

Par curiosité quel est l'âge de la code base ?

Toutes les semaines, j'ai du mal à le faire appliquer, les développeurs râlent déjà avec les reports toutes les 3 semaines xD. Une fois en début de sprint, ça me semble un bon compromis.

Après la durée n'est pas une constante, ça dépend de la quantité de modifications aussi. Tant que vous ne constatez pas une dégradation constante de la qualité de l'appli (j'entends par là quantité de defects) au fil du temps ça va.

Ok je prends note. Dans le cas où il y a des conflits sur la MR de report, un développeur la récupère en local et résout les conflits. Si entre temps la branche N+1 avance parce qu'un autre développeur a mergé, on est bien d'accord, le premier ne fait pas de rebase sur sa branche locale de résolution des conflits du merge ? Dois-je bloquer la branche N+1 (i.e dire aux développeurs de ne pas merger les features en attente) pendant la phase résolution des conflits de la MR de report ?

Quand tu fais un merge de n vers n+1 et qu'il y a un conflit, tirer la branche sur une machine de dev pour fixer les conflits est la seule solution pour permettre de finaliser la MR. GitLab t'indique d'ailleurs la marche à suivre. Mais il ne faut pas considérer la branche tirée par ce développeur dans ce cas de figure comme une feature branch privée. Il s'agit d'une opération de maintenance sur une branche d'intégration des devs, donc publique, donc rebase strictement interdit.

Normalement la gestion des MR devraient être confiée à un développeur avec des droits avancés qui a les droits de pousser directement sur les branches protected. Les branches d'intégration des devs doivent être passées en protected pour empêcher que les personnels avec des droits de développeur tout simple ne poussent directement dessus. Pour un dev lambda, il est interdit d'exécuter git push origin version-n. Absolument interdit. Il doit passer par une MR de sa branche vers la branche d'intégration de devs.

De même, un développeur lambda ne doit pas avoir les droits pour valider les MR. C'est au maître du git de gérer ça.

Le maître du git étant la seule personne à pouvoir valider les MR, le cas de figure que tu décris ne peut pas arriver. Il finit son merge de n vers n+1, il gère ses conflits, il pousse en direct sur version-n, il valide la MR, et c'est ensuite au développeur de rebaser sa branche et de la repousser sur sa MR.

Donc en résumé, il est nécessaire d'imposer une discipline via des limitations dans les outils (via les droits et les branches protégées), une seule personne gère le repo git avec les droits pleins (rôles Master et Owner dans GitLab), les développeurs ont des droits limités (developper dans GitLab de mémoire). Ils ne peuvent pas valider les MR vers les branches protected et encore moins pousser directement dessus.

Oui mais on nous a un peu forcé la main à mettre en place une architecture micro-service sans tenir compte des autres problématiques : DevOps inexistant chez nous, livraison par d'autres équipes à la main, recette peu automatisée à l'époque... ça commence à changer mais c'est très long...

Du microservice sans DevOps là c'est quand même bien bien chaud. Qui vous a forcé la main ? La personne qui a pris cette décision est dangereuse, elle est parfaitement inconsciente des conséquences de ses décisions.

Non pas forcément, disons que le problème touche surtout 2 repo, qui sont assez gros.

Assez gros ? Gros comment ? Mais vous êtes en microservices ? Je ne comprends pas !