Modèle de branches

De ce que j'ai compris :

• master : pour dev
• prod : pour la prod et hotfix la prod

Le tout en ayant une QA aussi fine qu'actuellement avant de merge sur master.

Alex, si tu pouvais éviter d'induire les gens en erreur en faisant des fausses récapitulations, ce serait pas plus mal.

Le dernier truc qui semblait faire consensus ne comporte pas de branche prod.

Pour moi, on a clairement 2 problèmes différents et spécifiques en fait :

Version pré-v1.0

État

Tant qu'on a pas réussi à stabiliser une version v1.0, on a des corrections gigantesques (plusieurs centaines de lignes modifiées) qui sont à peu près impossibles à merger (vers dev) sans risques de conflits. On a aussi une grosse masse de corrections qui arrivent.

Conséquence : on a pas les ressources pour merger tout ce bordel en permanence dans dev, qui du coup prends un retard monstrueux et devient de fait inutilisable (la moindre feature risque de provoquer de gros conflits avec les corrections massives).

Proposition de workflow

L'idée est en fait de ne travailler que sur master, en tant que branche de release.

1. On stabilise une v1.0 sur master le plus vite possible.
2. Le scope de la v1.0 correspond uniquement aux issues de la milestone v1.0 sur Github
3. On ne merge rien sur dev tant que la v1.0 n'est pas stabilisée. Le développement de features non prioritaire est autorisé, mais elles attendront. Les développeurs sont mis au courant de cet état de fait.
4. Il est interdit de corriger sur dev des problèmes corrigés sur la branche de relase master (pour prévenir les conflits)
5. Une fois la v1.0 stabilisée, on merge les modifs sur prod (facile) et sur dev (merge sale à prévoir, mais pas trop si on s'interdit de trop modifier dev – en particulier les corrections parallèles)
6. On MEP la v1.0
7. On supprime master (sisi, cf infra) et on passe au workflow suivant

Avantages / Pourquoi ça devrait marcher

• On corrige le plus urgent
• On évite le travail sur des branches parallèles donc les conflits
• On décourage la dispersion du travail sur des fonctionnalités non prioritaires
• On évite de perdre du temps à faire des merges dans tous les sens

Inconvénients

• Il y a un côté frustrant à ne pas pouvoir faire avancer des fonctionnalités non urgentes
• Ça implique d'être intraitable au niveau du merge des issues : si une issue ne concerne pas un ticket v1.0, elle n'est pas mergée, point barre

Versions > v1.0

État

Là normalement, on est dans un état "suffisamment stable". Conséquences :

• On peut se permettre d'utiliser une workflow de MEP à base de releases et de QA en préprod comme décrit ici
• On ne devrait plus avoir de bugs tellement importants qu'ils nécessitent d'énormes modifications (on a par contre des fonctionnalités pour lesquelles c'est le cas).

Proposition de workflow

L'idée est de suivre le Git Flow. Très exactement le Git Flow, pas notre version modifiée bâtarde qu'on suit actuellement. La seule modification serait le nom des branches.

C'est-à-dire :

1. Les arrivées fonctionnalités et corrections de gros bugs hors release se font via des PR.
2. Ces PR sont d'une taille raisonnable autant que possible (mieux vaut plusieurs PR compréhensibles qu'une PR géante)
3. Ces PR sont mergées dans dev (develop dans le standard), après une QA légère. dev ne devrait contenir que des merge de PR, aucun commit direct.
4. Quand on a assez de nouveautés dans dev (mais pas trop), on décide de faire une release. L'idée est de pouvoir vérifier et corriger les problèmes de cette release rapidement, disons en 2 semaines max entre le lancement de la release et sa MEP :
   1. On crée une nouvelle branche de release (contrairement à aujourd'hui où on utilise master), typiquement du nom de la version (ex : release-v1.2)
   2. La branche est balancée en préprod, avec un dump des données de prod. On teste un max sur la préprod.
   3. Si on en a les ressources, les correctifs de la branche de release sont remontés sur dev. Sinon, tant pis.
5. Une fois la branche de release bien stabilisée, on la met en prod :
   1. On merge la branche de release dans dev. Si on a pas pu merger les correctifs indépendamment, tant pis : ils devrait y en avoir peu, plutôt petits, et la procédure de release devrait être assez courte pour que ça ne pose pas de vrai problème de merge (contrairement à aujourd'hui).
   2. On merge la branche de relase dans prod (master dans le standard) (cf infra)
   3. On taggue
   4. On MEP
   5. On supprime la branche de release, qui est devenue inutile

On a donc un workflow a 2 branches (dev – qui devient la branche principale et prod), 3 pendant les périodes de release.

Pour que ça fonctionne, l'important est de choisir le contenu des releases de façon à conserver un cycle de stabilisation court.

Pourquoi je propose de garder la branche prod

Théoriquement on pourrait la supprimer, en conservant les branches de release et en les tagguant.

Je propose néanmoins de garder la branche prod pour les raisons suivantes :

• Facilité de faire des hotfix urgents sur la prod, même pendant la période de stabilisation (on peut s'en sortir sans, mais ça nécessite de repartir de tags et de réfléchir à des trucs pas nets)
• Principe de moindre surprise : le workflow suppose que cette branche existe
• Elle ne coûte rien à maintenir, puisque aucun merge dans cette branche n'est sensé poser de problème
• On peut benner les branches de stabilisation sans scrupule ni risque de perdre des commits
• On a en permanence seulement 2 ou 3 branches (sur le dépôt principal, les branches de features sont sur les fork) au lieu de (nombre de releases + 2) ou de (1 ou 2 mais avec les tags sur dev)

Avantages / Pourquoi ça devrait marcher

• Aucune surprise sur le workflow : il est connu et documenté de partout. Et on sait qu'il fonctionne.
• Le cycle de release court devrait nous éviter les problèmes actuels (merges invraisemblables muliples et coûteux, branche dev bloquée pendant 107 ans donc inutilisable, etc)
• Il permet d'alléger la QA : on peut se contenter d'une QA légère sur les PR quand on les merge dans dev, puisqu'on a une vraie QA complète au moment de la release.
• Ca aide le fonctionnement en releases (cf cette proposition et ci-dessous)

Inconvénients

• Si jamais on découvre qu'une fonctionnalité nécessite une grosse correction au moment de la stabilisation, on peut avoir un merge dans dev assez douloureux
• Tout le monde doit respecter le workflow : tout ajout de fonctionnalité sauvage dans la branche de stabilisation risque de provoquer des conflits
• La stabilisation peut être délicate si les PR qu'on a sélectionnées pour la release s'avèrent bugguées.

Pourquoi il est important de faire des releases et d'éviter la rolling-release

Principalement parce que la qualité est une grosse attente de la part de notre public. Les mises en production en mode "on met ce qu'on a en prod et on corrige vite fait les gros bugs" ont été tentées par un autre site, avec le résultat que l'on sait. Il nous a explicitement été demandé de ne pas fonctionner selon ce mode dans les différents topics : un fonctionnement par releases / QA sur préprod devrait permettre d'éviter les plus gros bugs.

Alors je sais, "le mode web" serait plutôt de mettre à jour souvent et de considérer qu'on est jamais 100% finis.

Mais pour moi ce n'est pas incompatible, puisque :

• Les releases ne correspondent pas à un état "fini" mais à un état "suffisamment stable pour être mis à la disposition du public".
• On ne parle pas de faire des gigantesques releases tous les 2 ans, mais des petites releases fréquentes, ce qui du point de vue utilisateur nous rapproche de la rolling release, le contrôle qualité sur l'ensemble de l'application en plus.

Quand on a assez de nouveautés dans dev (mais pas trop), on décide de faire une release. L'idée est de pouvoir vérifier et corriger les problèmes de cette release rapidement, disons en 2 semaines max entre le lancement de la release et sa MEP :

Pourquoi il est important de faire des releases et d'éviter la rolling-release

En fait, c'est presque une rolling-release : tous les 15 jours on balance ce qu'on a de neuf… ça sera stable et régulier grâce à la QA.

Donc personnellement, ça me va.

Pour info, j'ai MàJ la branche dev par rapport à la master. Il n'y a qu'un test qui ne passe pas, erreur mineure.

define: "QA Legere"

Moi ça me va. En gros, on retourne en freeze et on pousse à fond pour que la V1 arrive au plus vite, et on est ensuite "débarrassé" de l'ancien workflow … On signe ou ?

(N'oubliez pas non plus, et je sais que je suis chiant avec ça, que la milestone v1.0 est encore difficile à atteindre)

On vérifie que le truc fonctionne et qu'il n'y a pas d'énorme connerie dans le code, mais sans forcément re-tester tout le processus et tous les cas pathologiques à chaque fois.

En fait je me dis que dans bien des cas, si on a des tests fiables et assez complets, on pourrait presque se passer de tests humains ici, et n'y faire qu'une revue de code.

Après tu connais sans doute mieux le processus de QA que moi, sans doute y a-t-il des actions faites à chaque QA qu'on ne serait plus obligés de faire ici (parce qu'ils pourraient être repoussés en préprod).

Ca pourrait passer si les devs sont aussi rigoureux avant de pousser une PR. J'entends par la : tester correctement leurs modifs, rajouter un/des TU (ou demander de l'aide pour en faire) pour que chaque nouveau cas soit teste etc… (sur le back, en théorie il est possible d'avoir une couverture de 100%)

Juste une question pour essayer de comprendre mieux votre mode de fonctionnement pour les tests et la QA (le reste m'est trop étranger, désolé).

Dîtes-moi si j'ai bien suivi : vous vous orientez vers un process de tests unitaires bêton + quelques petits tests d'intégration à la main effectués par les dev à chaque PR. Par la suite les PR sont mergées puis le code déployé sur la preprod. (avec les données les plus proches possible de la prod).

Ce qui entraîne que les tests d'intégration poussés (et systématiques, à la rigueur avec des use case s'ajoutant ou disparaissant au fil des PR) sont effectués intensivement sur la préprod avant chaque release. A la rigueur, on peut lancer toute une batterie de tests d'intégration automatisés sur la preprod lorsqu'une PR est mergée.

Est-ce-que j'ai bon ?

Si c'est le cas c'est une énoooooooooorme avancée et je mâche mes mots, parce que ça veut dire qu'il suffit de faire une doc exhaustive des cas à tester et n'importe qui peut se charger d'un ou plusieurs tests manuels. Sans avoir besoin de ne rien installer sur son poste, avec une base de test qui est au plus proche de l'environnement de production (les pseudos à caractère pénibles, les messages horriblement longs, les X versions de tout plein de tutoriels, …). Mieux encore, la personne qui a rapporté un bug "mon tuto passe pas en bêta à l'aide au secours" peut tester par lui-même que le problème ne se reproduit plus, sans pour autant passer du temps à se construire un environnement de test.

Mais j'ai ptet' pas bien compris :\

@Javier,

C'est aussi ce vers quoi j'aimerais tendre, perso. Il reste encore quelques bords à lisser pour y arriver, cela dit, mais à terme c'est la solution idéale à mes yeux.

Tu as bon, enfin en ce qui concerne ce que j'ai proposé

(sur le back, en théorie il est possible d'avoir une couverture de 100%)

en terme de couverture, les 76% qu'on a sont déjà un petit record en soit.

Par contre en terme de sens et de fonctionnalité testé, là je pense qu'on en est encore loin, malheureusement.

Bah si vous vous orientez vers des tests d'intégration sur la preprod ça peut vite exploser en termes de couverture de tests. D'ailleurs s'il est possible de lancer sur la preprod le serveur avec une indication pour la couverture de tests (je n'ai utilisé que Cobertura en Java, c'est la même idée) ça sera mesurable. Et c'est un sacré indice de qualité pour la QA.

En outre, quand les gens en auront un peu marre de passer les mêmes tests à chaque fois, il suffira de les automatiser comme Nek l'a proposé, ce qui me semble beaucoup plus simple s'ils sont dans un projet à part, standalone (qui pourrait même être codé par des gens qui n'ont rien à voir avec le dév du site, dans un autre langage, sur une autre techno, …), que l'ont fait tourner à chaque fois qu'une nouvelle version est déployée sur la préprod.

Autant pour le workflow de dev je ne me prononcerai pas parce que c'est pas trop mon rayon, autant là, les dernières solutions proposées en terme de tests me semblent vraiment vraiment aller dans le bon sens ! C'est chouette.

Je relance ici : que décide-t-on ?

J'ai pas tout lu mais je viens là surtout pour témoigner. Car ce workflow c'est exactement celui qu'on utilise sur phpBB.

Donc nous on fonctionne avec 4 branches (je change les noms pour que se soit plus simple) :

• prod qui correspond à la version utilisée en prod sur le site
• develop-v1 qui correspond à la dernière version majeur stable publiée
• develop-v2 qui correspond à la version majeur qui est en cours de développement
• develop qui correspond aux versions futures

NB: par version majeur j'entends version qui contient autre chose que des bug fix. Ainsi develop-v1 correspond à la 3.0.0-a1, 3.0.0-a2, .... 3.0.10, 3.0.11, 3.0.12, 3.0.13-dev et develop-v2 à 3.1.0-a1 .... 3.1.x

Concernant les PRs, on fonctionne comme ça: - develop-v1 n'accepte que des bugs fix - develop-v2 accepte bug fix et improvement jusqu'au stade RC (souvent la frontière entre els deux est faible) et n'accepte plus que des bug fix clairement identifiés après - develop accepte tout

En général on cré develop-vx dès qu'on commence à réellement travailler sur la version vx-a1-dev (developpement de la alpha 1). Ce qui fait que develop est surtout utilisé entre v2-b1-dev et v2 (la version stable publiée)

Ensuite au niveau des merge, on base toujours la PRs sur la version la plus ancienne à laquelle la PRs s'applique (ainsi un bug fix de la v1 sera toujours basé sur develop-v1) et ensuite on merge ainsi :

1. merge en –no-ff de la PR dans develop-v1
2. merge en –no-ff de develop-v1 dans develop-v2 (avec résolution des conflits si besoins et si les conflits sont trop importants on demande à l'auteur de la PRs de fournir un second PR, basé sur develop-v2 et contenant les commit de la PRs initiale ainsi que le merge dans develop-v2 et l'on merge ainsi : merge de fix-v1 dans develop-v1, merge de fix-v2 dans develop-v2, merge de develop-v1 dans develop-v2)
3. merge en –no-ff de develop-v2 dans develop

et après, quand on veut publier la version sur le site, merge en –no-ff de de la develop correspondante dans prod (ou directement du tag car toutes les versions publiées sont taggées)

EDIT: C'est un peux compliqué à mettre en forme, donc si vous avez des questions n'hésitez pas. EDIT2: on n'utilise plus master

Dans notre cas, vu nos ressources, ce que tu dis ça revient donc à

• prod
• dev

On a pas assez de monde pour avoir 50 branches de dev, et globalement l'utilité d'une nouvelle branche ne se fera ressentir que lors qu'un gros refactoring ou une nouvelle version sera en développement. Donc finalement, selon moi, on en revient à ma proposition initiale : deux branches.

Ca reviens plutôt à 3 branches:

• prod
• support (que du bug fix)
• dev (nouvelles features)

Ainsi tu ne fais jamais rien directement sur prod, la branche correspond toujours exactement au statut actuel du site. Ca permet de merge des bug fix et de les tester correctement en pre-prod (générallement synchronisée avec la branche support dans ce cas là je pense) avant de les intégrer dans la version en prod. Le tout en gardant une branche qui est synchrone avec la version qui est réellement en prod.

support (que du bug fix)

Ainsi tu ne fais jamais rien directement sur prod, la branche correspond toujours exactement au statut actuel du site.

Pourquoi faire ? Il suffit d'avoir le commit de la prod (avec les releases) et on a le statut de la prod dans l'historique de la branche prod, et on bugfix sur cette même branche.

En fait, ce qu'il faut prendre en compte c'est pas l'aspect théorique "ça fait beau sur le papier" mais "on est pas nombreux, il faut que ce soit gérable".

Avec deux branches : on se concentre sur le dev/bugfix sur l'une et de hotfix sur l'autre.

Si on garde 3 branches, on reste sur le modèle actuel et qu'on arrive pas à maintenir de toute évidence. C'est un site web, pas un projet avec 1000 contributeurs réguliers.

En fait c'est juste que j'étais sur l'optique d'une synchro automatique du site avec la branche de prod mais sinon oui, ça revient exactement au même ça reste du travail avec 2 branches. Une pour le debug de la version actuelle et une pour la prochaine. Et si la PRs ne rentre dans aucun des deux branches (car elle est vraiment vraiment trop grosse pour être inclus dans la prochaine version qui est déjà bien avancée) et ben tu la garde de coté et se sera la première à être merge une fois que dev sera deveu prod. (mais dans ce cas il peut être une bonne idée de nommer les branches non pas dev et prod mais en fonction de leur version. Ainsi tu t'y retrouve plus facillement et il n'y a pas besoins de renommer des branches distantes lors du passage de dev à prod, surtout que en réalité ce n'est pas prod mais plutôt pre-prod.

Je vote pour une refonte de notre modele de commit !!

Ce que j'aime bien, c'est que :

• on est sur trois branches ;
• l'idée c'est d'en changer parce que c'est pas maintenable ;
• à chaque fois que je parle de deux branches seulement, je me prends des -1 sans explication.

Donc, quel est l'avis de ces gens qui ne s'expriment visiblement pas ? Ou plus généralement : quelle est la conclusion de ce débat ? Très sincèrement, je n'y comprends plus rien.