Modèle de branches

Parce que ça fait des pages qu'on dit que 2 branches ça pose d'autres problèmes et que tu n'as pas apporté de nouvel argument en faveur de ton modèle ?

Personnellement ça fait 10 jours que j'ai proposé ceci, avec tous les détails pour gérer à la fois la situation courante et la situation future. Sauf que visiblement tout le monde est en vacances et/ou préfère le statu quo.

En temps normal, notre DI prend la responsabilité de trancher quand le débat n'avance plus parce que tout le monde reste sur ses positions.

J'ai cru comprendre que nous avions un second DI maintenant …

Là c'est différent : il n'y a pas de débat, c'est bien mon problème. Surtout vu le bazar que ça a été la dernière fois qu'on a décidé d'un truc qui ne faisait pas consensus.

Alors, si vous voulez, on peut la jouer comme ça :

• Vous avez quelques jours pour vous exprimer (disons, la fin du WE).
• Si personne n'a réagi avec de vraies contre-propositions d'ici là, le mode de fonctionnement que j'ai proposé est accepté.
• À partir de là, c'est trop tard pour râler ou faire de petites piques : soit vous proposez un autre modèle complet qui résout clairement tous les problèmes que vous remontez, soit votre avis n'a aucun intérêt et donc sera ignoré.

Je trouve quand même dommage d'en arriver là, surtout sur un sujet qui semblait déchainer les passions à ce point.

Moi la proposition de SF me va beaucoup mieux que le modèle proposé par Alex.

Même si j'ai délibéremment choisi de ne plus m'impliquer dans le dev, je fais parti de ceux qui étaient d'accord avec le workflow de SF.

En gros, Alex, faut comprendre que ce que SF propose, c'est en gros un modèle à 2 branches… et demies. Actuellement, c'est un modèle à 3 branches, qui est fumeux, car une branche est délaissée. Avec le workflow de SF, on a en gros 2 branches (prod, dev), et une "demie" branche dans le sens où elle est éphémère… Et c'est ce que je proposais avant.

Je trouve que c'est un bon compromis.

Idem. J'ai l'impression que ce débat tourne en rond depuis deux semaines parce que personne ne prend la peine de comprendre ce que proposent les autres pour déclarer "je suis d'accord avec ça".

Merci à SpaceFox d'avoir pris le temps de rédiger ça, j'étais passé à coté de son message.

Bon, je m'en vais donner mon avis sur le workflow défini ici ainsi que le complément donné là.

Version pré-v1.0

On a pas encore atteint la v1.0, et on annonce clairement qu'on ne merge rien dans dev, moi j'appelle ça un freeze, et donc pourquoi laisser la branche dev vivante. Je pense qu'il faut tout simplement tuer la dev maintenant et la recréer lorsqu'on aura atteint la v1.0 et qu'on ne sera donc plus en freeze.

Versions > v1.0

Pré-réquis à ça : Avoir une préprod fonctionnelle et iso prod. Et donc pour moi c'est une tâche (issue ?) manquante quelque part qui devrait être dans les issues de release de la V1.0

Ce point me semble flou, il faut un truc assez clair. Qu'appelle t-on PR géante ? plus de 10 commit ? plus de 5 fichiers modifiés ? delta (ligne ajoutées - lignes supprimée) > 100 ? Étant donné que ça me semble assez subjectif, il faudrait clairement expliciter ce point.

A expliciter encore mieux. Car il me semble qu'aujourd'hui les tests joue le rôle de QA légère. Et j'aurai tendance à dire, quitte à faire de la QA légère autant se concentrer sur l'écriture de test. Pour moi donc, faire de la QA légère signifierai juste valider que le développeur à écrit un test qui couvre la fonctionnalité qu'il a codé et que travis ne gueule pas.

On ne peut pas tantpiriser ici. Pour moi, ne pas remonter une correction vers la dev, c'est la porte d'entrée aux conflits le jour du merge. On se retrouve avec des cas batards, ou tout ceux qui essayent de bosser à partir de la branche dev, doivent se manger les bugs qui sont pourtant fixés dans la branche de release, mais qui ne sont pas remontés.

Voila en gros, mes légères remarques sur le sujet.

Je pense qu'il faut tout simplement tuer la dev maintenant et la recréer lorsqu'on aura atteint la v1.0 et qu'on ne sera donc plus en freeze.

A ma connaissance on ne peut pas, parce qu'on a des développements qui ont été faits sur cette dev.

Qu'appelle t-on PR géante ? plus de 10 commit ? plus de 5 fichiers modifiés ? delta (ligne ajoutées - lignes supprimée) > 100 ? Étant donné que ça me semble assez subjectif, il faudrait clairement expliciter ce point.

On ne peut pas mettre de métriques ici, c'est à voir au cas par cas. Les PR problématiques, c'est celles qui touchent plusieurs tickets qui ne sont pas forcément liés, celles qui touchent à plusieurs morceaux indépendants de l'application.

Pour faire encore plus clair : ce que je ne veux plus voir, c'est une PR qui dit "J'ai fait A, et tant que j'y étais j'ai corrigé le bug B".

A expliciter encore mieux. Car il me semble qu'aujourd'hui les tests joue le rôle de QA légère. Et j'aurai tendance à dire, quitte à faire de la QA légère autant se concentrer sur l'écriture de test. Pour moi donc, faire de la QA légère signifierai juste valider que le développeur à écrit un test qui couvre la fonctionnalité qu'il a codé et que travis ne gueule pas.

Pour tous les cas où un test est faisable, ça me paraît bien, et ça nous oblige à faire des tests (ce qu'on ne fait pas aujourd'hui).

Pour les cas non testables automatiquement, il s'agit de vérifier que ce qui a été développé fonctionne. Pour les effets de bord et autres, c'est l'objet de la vraie QA sur la préprod.

On ne peut pas tantpiriser ici. Pour moi, ne pas remonter une correction vers la dev, c'est la porte d'entrée aux conflits le jour du merge. On se retrouve avec des cas batards, ou tout ceux qui essayent de bosser à partir de la branche dev, doivent se manger les bugs qui sont pourtant fixés dans la branche de release, mais qui ne sont pas remontés.

En fait, si. Toute l'astuce qui permet le fonctionnement de ma proposition est là.

Aujourd'hui, notre problème c'est qu'on ne peut pas faire remonter les corrections au fur et à mesure parce que c'est un boulot de dingue.

Le principe ici c'est qu'on part d'une branche de dev à peu près stable et que le processus de release est court.

Donc oui, les gens qui bossent sur dev se prennent les bugs qui sont fixés sur la release. Tant pis. Pourquoi "tant pis" et surtout pourquoi ce n'est pas gênant ?

1. Parce que comme la branche de dev reste normalement à peu près stable (grâce à la QA légère avant d'introduire une fonctionnalité) les bugs "fixés sur la release" ne devraient pas être critiques (on a les hotfix pour les bugs critiques qui ont réussi à aller en prod).
2. Parce que dans le pire des cas la correction sera remontée sous deux semaines, ce qui est la durée de vie maximale de la branche de release. Si elle dure trop longtemps parce qu'elle n'était pas prête et trop bugguée, il suffit de l'annuler en remontant toutes les corrections faites vers le dev, et de ne jamais la mettre en prod.

Ok dac. En fait, globalement, tout le monde est d'accord, mais personne ne voit la chose sous le même angle. Enfin pour moi c'est feu vert si c'est bien "deux branches et demi", et qu'en gros, actuellement, la branche dev dégage, et qu'on dev sur master en étant freeze (ou pas, mais en insistant très très très fortement sur les bugfix en priorité).

A noter que j'avais mis à niveau master et dev entre eux il y a 15 jours (ou un truc comme ça) et ça a été relativement rapide et simple. Donc actuellement ce qu'il faudrait faire c'est merge l'une des branche dans l'autre et virer celle qu'on veut : peu importe laquelle, le but étant d'avoir une branche prod et une branche de développement, qui dans l'état actuel des choses n'est dédié qu'à la stabilisation vers une v1.

Le principe ici c'est qu'on part d'une branche de dev à peu près stable et que le processus de release est court.

Donc oui, les gens qui bossent sur dev se prennent les bugs qui sont fixés sur la release. Tant pis. Pourquoi "tant pis" et surtout pourquoi ce n'est pas gênant ? […]

J'insiste là dessus, mais la tanpirisation ici ne peut pas faire partie d'un workflow de travail. Si on considère la branche dev, comme branche de travail, il faut qu'elle soit maintenue à jour au même titre que la branche de release. Pourquoi ?

1. Parce que celui qui développe sur la branche de dev en cours, risque d'avoir de grosses surprises le jour ou il poussera son code, s'il ne se merge pas lui même tout le temps avec la branches de release.
2. Parce que si je développe une fonctionnalité sur une branche instable (vu que la branche release ne m'est pas remontée) et que celle si est mergée sur la dev avant le merge de la release vers la dev, c'est la porte ouverte aux conflits. Et je précise bien qu'un conflit entre deux branches indépendantes, est la porte ouverte aux bugs "fonctionnels".
3. Parce que, soyons honnêtes, pour que cette tanpirisation marche, il faudrait partir du principe que dès le lancement d'une release, tout le monde arrête de bosser sur la dev, et stabilise la master.

En considérant le point 3, j'ai du mal à voir l’intérêt de s'embêter à se créer des branches de release si c'est pour ne plus maintenir la dev. Il suffit de garder une branche dev et une branche prod, et de tant à autres, dire à tout le monde "On rentre en phase de release … donc freeze des features jusqu'à la MEP". Au moins ça aura le mérite d'être clair, parce que c'est ça la traduction du tant pis.

Je rappelle à tout hasard que les branches de release permettent de corriger les bugs détectés pendant le test en préprod et qui nécessitent une correction immédiate. Ces bugs devraient donc être rares.

Exemples :

• Pendant le tests de la release, on détecte un problème jamais détecté avant. Il est corrigé sur dev¹ et ne fait pas partie de la release.
• Pendant le tests de la release, on détecte un problème sur un élément qui ne fait pas partie de la release (module non impacté par les commits qu'on release). Il est corrigé sur dev et ne fait pas partie de la release.
• Pendant le tests de la release, on détecte qu'une correction qu'on essaie de releaser ne fonctionne pas exactement comme prévu. Dans ce cas seulement, on corrige sur la branche de release.

Donc, pour que les problèmes que tu décris arrivent, il faut :

1. Que quelqu'un merge une fonctionnalité/une correction de bug standard dans dev au moment où on a une release en prépartion
2. et qu'on ait un bug dans cette release
3. et que ce bug soit lié à la release (cf ci-dessus) ce qui nous oblige à le corriger pour publier
4. et que la correction de ce bug impacte les mêmes fichiers que la fonctionnalité mergée

Dans ce cas, on a un risque de merge non trivial.

Personnellement, je pense que ce risque est tout à fait acceptable, et qu'on peut se contenter de suivre le Git Flow tel que décrit (qui, je le rappelle, n'impose pas de remonter les correctifs de la branche de release au fur et à mesure).

Il n'y a donc pas à s'inquiéter outre mesure de merges vicieux ou de geler la branche de dev pendant une release. On peut par contre imaginer de geler les devs si on détecte un problème vicieux dans la release (au cas par cas donc, et en relation avec les PR en cours).

Je n'ai aucun problème à me baser sur un workflow qui est connu pour fonctionner ; surtout face à des problématiques qui sont pour l'instant théorique et qui ont un risque faible d'arriver.

Ces cas, ne sont clairement pas triviaux. Je peux en faire une liste si tu veux.

• X developpe une fonctionnalité d'upload d'image automatique en Ajax sur la branche dev
• pendant ce temps en release, on se rend compte qu'on a un bug dans le nommage des galleries.
• le bug est fixé en release et pas remonté en dev.
• pendant ce temps X continue de développer par dessus le bug, avec 80% de chance de livrer une PR foireuse.

• X developpe une fonctionnalité d'ajout du filtre par tag
• Manque de bol, pendant la release on se rend compte que les autres on un problème, ils ne s'affichent pas pour les invités.
• Le bug est fixé et n'est pas remonté en dev
• Monsieur X à encore 80% de livrer une PR foireuse.

• Monsieur X développe un système de navigation au clavier
• Pendant la release on se rend compte qu'il y'a un bug du au nommage d'une classe css.
• Le bug est fixé (changement du nom de la classe) et n'est pas remonté dans dev
• Monsieur X a donc toutes les chances de se retrouver encore avec une PR foireuse.

Des cas qui vous semble peut-être triviaux, mais qui sont très clairement évidents. On ne les a pas encore rencontrés parce que depuis on est toujours en freeze (officiel, ouis officieux) et on s'interdit les merges dans la dev, mais dès qu'on passe en open-features, je ne vois pas comment ça peut marcher.

Après si vous considérez que le risque est acceptables, pourquoi pas, mais j'ai comme l'impression que ça fera comme la fois précédente,

• on propose un workflow
• tout le monde dit oui,
• deux semaines plus tard dans la pratique on se dit, "Ah mais non, la branche tel ne sert à rien" ou encore "c'est le bordayle dans les branches on sait plus ou faire la PR", etc.
• on perd du temps

M'enfin, j'aurais tout de même exprimé mon avis que le principe selon lequel on oblige pas la remontée des bugfix des release vers la dev, est une mauvaise pratique.

Pour commencer, tes 3 cas tombent directement dans le cas que je décris à la fin : si on s'aperçoit qu'il y a un problème sur un point particulier, on ne merge pas les PR qui pourraient rentrer en conflit.

D'autre part, il faudrait vraiment un concours de circonstance extraordinaire pour que les cas que tu décris arrivent. Parce que si l'un des problèmes que tu décris est détecté pendant la release et qu'ils ne sont pas dus à une nouveautés de cette release, il ne seront pas corrigé sur la branche de release mais sur dev !

Donc pour qu'on ait des merges problématiques, en appliquant la règle du gel du merge si on détecte un problème lors des tests en préprod, il faut que toutes les conditions suivantes soient réunies :

1. La release en cours et une PR proposée pendant la release impactent une même fonctionnalité (plus exactement les mêmes fichiers)
2. La release a un problème sur les fichiers en question
3. Le problème est dû aux modifications embarquées dans la release et donc doit être corrigée
4. On a déjà mergé la PR (sinon, il suffit de la faire attendre et repartir de la nouvelle version)
5. Le merge obtenu n'est pas trivial

M'enfin, j'aurais tout de même exprimé mon avis que le principe selon lequel on oblige pas la remontée des bugfix des release vers la dev, est une mauvaise pratique.

Je passe sur le fait que ça se discute (le Git Flow, qui encadre beaucoup de choses, ne le mentionne pas comme tel).

Mon vrai problème, c'est que c'est exactement ce qui nous a foutu dedans jusqu'ici : on a pas eu les ressources nécessaires pour le faire.

De plus, le modèle proposé fait que les corrections de release devraient être exceptionnelles.

Le modèle qui a échoué jusqu'ici l'a été parce qu'il n'a jamais été convenablement réfléchit. On ne s'était jamais posé la question de la volumétrie des commits à remonter sur la branche de dev. On s'est retrouvé avec des bugs corrigés séparément des deux côtés parce qu'il y a eu des mauvaises communications.

Le modèle que je propose échoue et devient merdique si on est mauvais et qu'on se retrouve avec des dizaines de corrections à faire sur la branche de release.

Du coup, la question du freeze ou non pendant la release se résume à une question : est-qu'on est capable de faire du boulot propre ?

PS : Si je résume donc nos positions respectives :

• Tu sembles partir du principe qu'on va faire de la merde et donc qu'on va se retrouver avec des conflits
• Je pars du principe qu'on peut faire un minimum confiance aux gens et tester un workflow pas trop chiant. Quitte à passer au tien s'il s'avère que j'avais tort.

Je pars du principe que tout peux arriver (et donc de la merde aussi) et que c'est dommage de revenir toute les deux semaines modifier notre workflow.

Mais au moins je l'ai exprimé.

J'ai bien compris ça, mais quelle est la part de risque pour toi ? Tu penses vraiment qu'on est incapables de produire du code assez propre pour qu'on finisse par se manger des merges moisis dans la tronche ?

Si on s'inscrit dans la vision qu'on a tous souhaité pour ZdS dès le début, à savoir, un modèle de développement assez ouvert et simple pour que n'importe qui puisse y contribuer quelque soit ses compétences, on est obligé de considérer dans notre workflow l'arrivée de nouveaux contributeurs qui nous apportent le meilleur (comme toi par exemple) ou encore le pire.

D'accord, mais pour moi "le pire" va arriver, mais sera bloqué au moment de la PR.

Bon, j'ai bien réfléchi, alors voilà :

1. On tente ce que je propose - je met à jour la doc à ce sujet.
2. Je prends le risque d'avoir des conflits ; si jamais un jour on se retrouve avec des merges pourris :
   1. Je me charge personnellement de les résoudre
   2. On passe au workflow de firm1 (le même mais en freezant pendant la release)
   3. Je paie une bière à firm1 (ou un fromage, un truc quoi)

Bien sûr, ça ne vaut que si le workflow est respecté.

Ça sera de la Guinness pour moi Monsieur.

Ne pas lire, je garde juste pour mémoire et je repost demain plus clair, plus propre

Bon, tout d'abord désolé pour ceux qui ont essayé, en vain, de lire et de comprendre mes posts précédents… Maintenant je vais tenter de recommencer plus clair, plus court et plus précis

Donc tout d'abord j'approuve entièrement le workflow proposé par SpaceFox. C'est un très bon modèle qui a fait ses preuves sur une très grande quantité de projets ayant tous leur spécificité.

Sinon, pour revenir aux conflits entre dev et la branche de release.
Tout d'abord il faut savoir que à moins d'avoir énormément de bugs à corriger ce cas est relativement rare, sinon il y a plusieurs choses qui peuvent être tentés afin de transformer, si possible, le MAY du graph en MUST afin d'éviter au mainteneur (ou à un mainteneur suivant) d'avoir à résoudre le conflit lors de la fusion de la branche de release dans dev :

1
2
3
4
5
6
7

1. l'auteur cré son patch sous dans une branche bug-fix/10 basée sur la branche de release
2. On se rend compte que ça vas créer un conflit important lors de la fusion de la release dans dev
3. On demande à l'auteur du bug-fix si il est en mesure de résoudre le conflit lui même
4. Sinon, on peut eventuellement demander à celui qui a fournis le patch implémentant la ZEP qui est en conflit avec le bug-fix actuel si il est en mesure de résoudre le conflit
5. Sinon, on peut faire un appel à contribution pour demander si quelqu'un est en mesure de résoudre ce conflit
6. Sinon, si on peut attendre qu'un mainteneur à même de régler le conflit soit disponible (SpaceFox par exemple) et c'est donc lui qui ira fusionner le patch (la pull request)
7. Sinon, dans le pire des cas (c'est à dire quand personne ne peut résoudre le conflit et que l'on ne peut pas attendre) le mainteneur fusionne le patch dans la branche de release uniquement et on tombe sur le cas décrit par SpaceFox

Comment se passe la résolution du conflit par un tiers ?

1. l'auteur cré son patch sous dans une branche bug-fix/10 basée sur la branche de release
2. L'auteur, ou un autre contributeur, (on vas appeler cette personne Monsieur X) cré un nouvelle branche basée sur la branche de dev et appelée bug-fix/10-dev
3. Monsieur X fusionne la branche bug-fix/10 dans sa branche bug-fix/10-dev et résout le conflit à ce moment là
4. Il soumet sa branch sur github et notifie dans les commentaires du patch bug-fix/10 qu'il a résolu le conflit dans sa branche bug-fix/10-dev
5. Le mainteneur fusionne bug-fix/10 dans la branche de release
6. Le mainteneur fusionne bug-fix/10-dev dans la branche dev
7. Le mainteneur fusionne la branche de release dans la branche dev (à ce moment là il n'y doit y avoir, en principe, strictement aucun conflit)

Donc voilà, c'est une petite astuce qui, assumant que la personne la mieux à même de résoudre les conflits est souvent l'auteur du patch, d'essaye d'éviter autant que possible au mainteneur d'avoir à assumer cette tâche.

J'espère que maintenant c'est plus clair.

P.S Je me permet quand même au passage de redire se que SpaceFox a dit : en pratique c'est un point qui est relativement rare. En réalité ça ne peut vraiment se présenter que dans 2 cas :

1. La branche de realease a une durée de vie extrèmement longue (plus c'est plus plus ça a de chances d'arriver)
2. Un patch effectuant des changement vraiment très très lourd a été fusionné dans dev après la création de la branche de release et, avant le changement de release, un bug a été découvert sur la pré-prod.
   Ca peut arriver, mais en pratique, si on sait que la durée de vie de la branche de release est faible il est parfois meilleur d'attendre sa fin de vie pour fusionner les plus gros patchs

EDIT: Finallement c'est pas plus court, désolé… mais par contre ça devrait être beaucoup plus clair.