Modèle de branches

Salut les gens,

Aujourd'hui on a 2 branches :

1. master sur laquelle les gens développent
2. prod qui est les versions mises en prod et seulement elles

On vient de se rendre compte sur IRC qu'il en manque une : celle qu'on crée au moment des releases, sur laquelle on accepte uniquement les fix de la release en cours.

Voici le modèle que je propose :

1. prod la branche de prod
2. master, la branche de releases, qui n'accepte que des fix et qui est poussée régulièrement en préprod
3. develop, la branche de développement normale

Qu'en pensez-vous ?

Je vote pour.

En gros master ce serait prod + bugfix "le temps de la passer en préprod" ? ou j'ai pas compris ?

A ce moment là, quelle est la politique de merge? Non parce que le "développement normal", c'est vague et puis si je corrige une issue et qu'elle est validée dans master, il faut qu'elle le soit aussi dans dev non? Sinon on va se retrouver comme OC avec les "problèmes de branches" quand on mettra en prod.

En fait, à un instant T tu dit "OK, on va passer en prod".

À ce moment là tu merges develop dans master, et tu fais une grosse QA sur master avant de la passer en prod. Tu n'acceptes que les corrections de bugs sur master. Tu merges sur prod au moment de la MEP.

Ça permet de continuer à développer même quand on s'apprête à MEP.

PS : Quand tu mets en prod, tu merges master dans prod, et aussi master dans develop pour que develop aie les correctifs liés à la QA.

J'espère que j'ai été clair ?

ha ok, ça me va

En fait l'idée c'est d'arriver à ceci http://nvie.com/posts/a-successful-git-branching-model/ mais avec des noms de branches qu'on trouve plus clairs :

• develop sur le schema reste develop
• Les release branches seraient notre master
• master sur le schema_ est notre prod

Ceci parce que les outils ont tendance à considérer que master c'est la branche par défaut, donc c'est relativement facile de faire un commit malencontreux dessus.

Quant aux branches hotfixes il faut prier pour ne jamais en avoir besoin

Je vote pour également.

Ça rappel le modèle de dev d'Android, donc ca doit pas être une si mauvaise idée https://source.android.com/source/code-lines.html

J'ai pas tout lu, mais je tiens a signaler que je n'aime pas le terme "develop". Soit on abrege "dev" soit on l'écrit complétement "developpement". La comme ça c'est moche.

Je suis d'accord mais c'est à mettre en balance avec les conventions pourries de Git et le principe de moindre surprise.

Cela dit, comme on a commencé à bidouiller le standard…

Bon, firm1 a raison, quitte à bidouiller le standard autant faire simple.

Je re-créer dev et MAJ la doc.

Edit : C'est fait !

Je pense que s'encombrer d'une troisième branche est quelque chose d'overkill. La branche prod est la branche de release ; la branche master celle de développement.

Besoin d'un hotfix ? On fait une branche depuis prod histoire de le faire, qu'on merge ensuite dans prod… Et dans master. En même temps.

Besoin de checker en preprod ? On checkout master. Normalement, tout code qui s'y situe doit être stable, la QA ayant validé les modifs par les différentes PR faites qui y sont dirigées.

Bref, je trouve ça superflu.

Édit : double négation enlevée, pour notre cher président du CCDN.

Le git flow le dit très bien. On est censé vivre avec 2 branche. Une stable (notre prod) et une branche de travail (notre master) qui vit.

Le gitflow dit encore, que lorsqu'on se prépare a faire une release, on forke la branche de travail pour la fixer a fond pour la release. Dans notre cas ici, la release qu'on prépare est la beta-publique, il faut la fixer par devant et par derrière, pendant ce temps, notre branche de travail peut recevoir autre chose que du bugfix. Une fois que la branche de release est mise en prod (mergée dans la branche prod dans notre cas), on se retrouve donc avec 2 branches vivantes a nouveaux.

C'est écrit noir/blanc sur le doc du Gitflow.

Et va falloir en parler sinon ca va partir en cacahouetes si on est pas tous sur la meme longueur d'ondes pour travailler : https://github.com/zestedesavoir/zds-site/pull/1276#issuecomment-50009337

(perso : La branche dev me semble, a l'utilisation, superflu)

Yop tout le monde !

Ca commence à être le boxon entre dev de hotfix, features et hotures.

Je pense que le problème, c'est qu'on a annoncé une v1, mais que côté dev on est pas en v1, donc il commence à se rajouter des choses alors qu'à priori le freeze n'est pas levé puisqu'on est pas en v1, etc.

Du coup, ça serait cool d'avoir un résumé/point dev, de la part de notre DTC préféré, pour mettre tout le monde d'accord

Si on en crois ceci :

Etant donné qu'on est sortie de manière officielle, le freeze est cassé.

Je l'ai déjà dit mais je vais me répéter pour que ce soit clair :

• Le freeze est levé.

• La priorité 0 reste d'atteindre la milestone v1.

• On n'a PAS annoncé la v1. On a annoncé la sortie officielle : en théorie les deux auraient dû coïncider, dans la pratique ça n'a pas été possible, mais ça ne change rien.

Les nouvelles features ont donc actuellement la priorité la plus faible que ce soit en terme de dev ou de QA, et les issues en milestone v1 ont la priorité maximale.

Pour continuer la discussion du ticket linké par Eskimon.

donc autant adopter un principe de rolling release […]

En gros, on adopte plus le gitflow ? Dans ce cas, il faudrait aller en parler en dev zone.

Le principe de rolling release ne contrarie absolument pas le git-flow hein. L'idée du git-flow est d'avoir une branche de base (la branche de developpement, ou rien n'est développé dessus à part des merge de PRs), et des branches qui en partent. Ca indique d'avoir une branche de prod, qui est sync avec la branche de dev quand il le faut. D'ailleurs, plutôt que d'avoir des merges dans tous les sens (ce que je qualifie de "merge oedipiens" : on sait plus qui est le parent, l'enfant, …), il faut aps hésité, lors d'un déploiement en prod, à scratcher la branche et la recréer à neuf sur le point à MEP.

La branche de dev actuellement ne sert à rien, comme je l'ai déjà énoncé plusieurs fois dans ce topic (et que personne ne prenne l'habitude de m'écouter, mais ça va, j'ai pris l'habitude à force, d'où mon éloignement qui se fait de plus en plus sentir ; j'en ai honnêtement ras le bol). Même firm1 dit qu'il préfère pointer ses features sur la branche master… c'est dire.

La branche de release, c'est master en fait. Quand on veut faire une release (en gros, tagger le répo sur une version : v1.0, v1.0-RC, v1.2, … etc), LÀ on créer une branche "release", qui une fois qu'elle est suffisement fixée, pourra être renommée en prod. Ou carrément être utilisée pour la MEP, et pourquoi pas scratchée à la prochaine MEP.

En gros, voici comment je vois le truc (ça n'engage que moi, mais c'est un modèle qui a fait ses preuves), un . représentant un merge, un / un départ d'une branche

1
2
3
4
5
6
7

      -- fix
     / |
   ----. prod / release.. whatever
  /    |
-------.-- master (dev donc)

      merge de fix dans prod, puis dans master

On a besoin d'une nouvelle release ? OK, on scratch la branche prod, et on la recréé depuis master là où on a besoin. En gros, la branche de prod et master (développement donc) accueillent donc juste des merges. Pas de commits sauvage qui se baladent, spécialement pour la prod.

J'espère que ce dessin vous aidera un peu mieux à ce que j'essaye de véhiculer depuis maintenant quelques mois.

La branche de dev actuellement ne sert à rien

La branche de dev ne servait à rien jusqu'à la sortie officielle parce qu'on était en freeze, et elle ne servira pas à grand chose tant qu'on n'aura pas atteint la milestone v1.0 ni adopté notre rythme de croisière.

Le fait qu'on ait une branche de releases permet de stabiliser les features en vue d'une MEP qui correspond à une milestone. Pendant la stabilisation d'une MEP, il n'y aura pas de freeze au niveau développement, donc les nouvelles features continueront à arriver sur la branche de dev.

Par conséquent, la branche de dev ne pourra jamais être assez stable pour être mergée vers la prod et on a donc besoin de bosser sur deux branches différentes. Que ces deux branches soient permanentes où qu'on crée la branche de release à la volée, ça ne change rien du tout.

Je comprends ton point de vue, mais tu proposes simplement une autre implémentation du flow qui a été décidé ici, et qui ne me semble pas apporter grand chose de plus.

Je continue à penser que la branche dev est inutile, preuve en est l'actuel fonctionnement…

On est une poignée de dev. régulier, et d'autres occasionnels. Ca ne changera probablement jamais. On a pas 15000 PR à la fois, ni meme des tonnes de bugfix en meme temps. Notre code ne contient pas des milliers de sous projets/modules. Bref. Avoir trois branches dev/master/prod c'est juste chiant.

Avoir une branche master et une prod. c'est pratique. On se pose pas la question de savoir ou merger, on doit pas puller a chaque fois l'une ou l'autre ou les deux et on peut travailler efficacement. Les hotfixs peuvent venir et se repercuter facilement sur tout les contributeurs. Les nouvelles features aussi et on sait plus facilement qui travaille où (par exemple je suis en train de rajouter des tests, si firm1 m'avait pas dit "poulp en fait sur dev" on aurait eu le joli risque de temps perdu…).

Bref, trois branches c'est beau sur le papier, mais la faudrait jouer la carte de la pragmacité. On a deja du mal a faire de la QA correcte, si en plus il faut la faire sur deux niveaux on va plus y arriver, le projet va ralentir, les gens se demotiver etc…