Modèle de branches

Et je continue de savoir, par expérience, que du jour où la v1 sera atteinte et qu'on va scheduler des releases mineures, on ne pourra pas faire autrement que de QA-iser la branche d'intégration pendant que la dev continue d'accueillir les nouvelles features.

La vie d'une feature, c'est 3 étapes : développement, intégration/stabilisation, mise en prod. Si on n'a pas chacune de ces étapes sur une branche séparée des deux autres, alors on sera obligés de continuer à se taper des phases de freeze qui sont contraignantes pour tout le monde.

Je comprends que tout ca c'est bien et c'est beau comme théorie, mais la de ce que je vois c'est que tout les contributeurs réguliers grognent sur le système à trois branches parce que c'est ingérable pour coder pour le moment. On a une branche dev qui vit sa vie, une master qui fait aussi sa life dans son coin et prod' qui hérite de master de temps en temps… Bref, faudrait vraiment au plus tôt aligner les choses…

Dans ce cas peut-être faut-il alléger la QA sur dev et se concentrer sur master ?

Edit : Sachant par ailleurs que les hotfixes qui sont censés être faits sur master pour les features V1 sont prioritaires sur tout le reste et devraient être mergés régulièrement dans dev.

En gros la QA devrait tout bêtement ne plus s'occuper de ce qui est pushé sur dev pour l'instant.

En gros la QA devrait tout bêtement ne plus s'occuper de ce qui est pushé sur dev pour l'instant.

T’inquiètes, c'est déjà le cas Il y a aucune PR dev->master il me semble et on a déjà (des fois) du mal a avoir assez de ressources pour faire master->prod…

Le passage master -> prod est une formalité en principe. Tu parles des MEP en elles-mêmes ?

Oui pardon, je parle bien des merges "ma copie" -> master

En fait je viens de tilter ce qui me chiffonne… Vu que TOUT passe par une étape de PR/QA, la branche dev' est redondante de ta branche local, et c'est ça qui me gène/freine. Personne ne pousse en direct donc on a toujours le contrôle de ce qui se passe sur master. (N'oublions pas qu'on est moins d'une dizaine de dev' + QAtiseur et que ca restera comme ca pour un moment je pense)

Moi je t'invite à lire les commentaires ici nohar : https://github.com/zestedesavoir/zds-site/pull/1276

Ce que j'y vois c'est une PR qui ajoute une feature, milestone v2, avec demande de merge explicite dans master.

Si on suit la logique définie, ça va dans dev et ça sera rabattu dans master après la v1. Quand on bossera sur une v1.1 (par exemple).

Je suis d'accord. Et je me demande également pourquoi cette PR a été faite aussi tôt.

Edit : bon. Si on allégeait le process de QA ? Voilà ce que je propose.

Sans supprimer pour le moment la branche dev et en se concentrant sur les hotfixes sur master pour le moment :

• QA light sur les PR : les devs testent leur code avant de pusher et la PR sert juste de review rapide.

• QA en continu sur master sur la preprod.

Ça implique que la fermeture d'une PR n'entraîne pas fermeture des issues : la PR passe la première vérif rapide, elle est mergée dans master puis fermée, et le gros de la QA est réalisé en continu sur master, ce qui entraîne soit fermeture de l'issue, soit reouverture de la PR ou l'ouverture d'une nouvelle PR.

En gros on se centre sur les issues plutôt que sur les PR.

Et on avisera plus tard du sort de dev.

Vous en pensez quoi ?

Et on avisera plus tard du sort de dev.

Donc actuellement on reprend ce qu'il y a dedans et on le merge sur master ? Car y a eu du travail de fait dessus.

Non pour l'instant on n'y touche pas simplement parce qu'on est en train de chercher à releaser la v1.0, donc que les fixes doivent venir sur master, donc que selon les prios il n'y a pas besoin de toucher à dev.

Bien sûr si un dev s' est planté et a PR un hotfix v1 sur dev, ça migre sur Master, comme prévu par le workflow.

Je vais apporter mes 2 cents en faisant un retour d’expérience sur mon quotidien pro.

Pour le contexte, je bosse sur le framework multimedia Android pour un producteur de smartphone sous ce systeme. L'environnement de travail est complexe (plusieurs depot git, des milliers de contributeurs du côté open source de la chose et plusieurs centaines du cote "closed source" aussi). Bref, c'est un grossse machine. La division est ainsi :

• Une branche "commune" à tout le monde. On se met à jour régulièrement à partir de cette dernière.
• Tout jours/heures des mises à jour sont inséré dans cette grosse branche. chaque jour (plus ou moins) une build est faite + taggué. (on a aussi des branches de cette dernière pour des déclinaisons particuliers (personnalisation opérateur etc))
• Chaque dev à sur sa machine une copie du code et bidouille dessus. Quand il veut pousser dessus, il fait sa branche sur sa machine avec ses modifs et pousse vers la principale. Une PR (ce qui s'en approche en tout cas) est crée automatiquement.
• Cette dernière est alors analysé par l'équipe proche pour de la review de code et quand suffisamment de personne approuve cette relecture de code (et le message de commit qui est pointilleux) et que les tests auto passent, un plus haut gradé vient vérifier a son tour pour approuver le tout. Le dev' a alors le droit de merger son code dans la branche principale qui sera alors visible pour tous apres le prochain tag/build.

Et voila comment ca se passe pour un projet dont le source fait plusieurs Giga, réunit des milliers de personnes sur plusieurs continents.

On a en résumé : Une branche de production qui part sur les produits finaux, une branche dev sur laquelle le travail régulier est mergé, et des branches dev qui sont les branches de travail sur les copies locales de tout le monde. Ca fonctionne comme ca chez moi et c'est peu ou prou le workflow de tout le code de l'AOSP (Android OpenSource Project). (Andro tu confirmes ?)

Je me demande donc ce qui nous empêche de faire pareil, ou tout du moins d'essayer de faire pareil…

La seule différence, c'est que nous les features ont peu les pousser alors que pour Android les features sont sur une branche en avance de phase faites par google (donc nous il faut qu'on s'organise autrement).

Je ne connais pas dans les détails le workflow adopté pour Android mais c'est quand même assez différent des workflows que vous proposez pour notre projet (les deux j'entends).

En résumé : A tout moment, le repo d'Android possède une branche release et une branche de développement pour la dernière version publiée. La communauté (et des constructeurs de téléphones) contribuent uniquement sur la branche de développement qui sont, par la suite, mergés sur la branche release correspondante avec une revue du code.

En parallèle, Google va créer une branche en interne pour la prochaine version (et ils ont leur propre organisation en interne). A partir d'un moment, ils vont rendre cette branche publique pour accepter les contributions externes. Ils vont alors faire une release et créer une branche de développement publique dans la foulée. Google va répercuter les changements nécessaires de la précédente branche vers la nouvelle, faire une release et la nouvelle branche deviendra la branche de référence.

Voilà, j'espère avoir été plus ou moins clair. Cela dit, tout ceci c'est dans la théorie. En pratique, il y a un peu plus de branches …

Au bureau, on adopte à peu près le même workflow qu'Eskimon. Je détaillerai un peu plus quand j'aurai un peu plus de temps.

Le fait qu'on soit plus en freeze, ça veut dire qu'on a le droit de balancer des nouvelles features de la dev vers la master ? Ou que des petites features dans la master directement ? Car si c'est dans dev, ça va être chiant de pick telle ou telle feature, ça sera tout rien.

Est-ce utile de chercher à stabiliser une version, sachant qu'on travail sur un site web et qu'il y a des choses qui bug qui arrivent en prod ? En gros, est-ce qu'on a tant intérêt à avoir des stabilisations à chaque release ? Autant jusqu'ici, j'ai saisi l'intérêt du freeze, parce que c'était vraiment pété de bugs de partout. Autant, à partir de maintenant si on peut ajouter de nouvelles features, on les balance dans master, on les test en QA, on les test en pre-prod, on stabilise, puis on merge master sur prod et ça sera donc poussé à la prochaine MEP.

Je fais partie de ceux qui pense qu'une branche est inutile quoi qu'on fasse, quoi qu'on en dise. En gros, on décalerais tout simplement d'un cran : la prod, ça serait la master actuelle (avec les tags on a déjà un pointeur vers la version en prod, on peut continuer à hotfix par dessus) et la master pour dev. Car au final, la branche de prod, elle ne sert à rien actuellement puisqu'elle n'est qu'une copie de master à une version donnée, un tag suffit pour ça, il y en a donc on peut hotfix dessus.

So j'en arrive à la conclusion suivante :

• prod, avec des tags : reçoit les hotfix, QA fine + preprod ;
• master : on dev dessus, QA + Code review à chaque PR.

Au besoin, on crée des branches plus spécifiques : genre dev d'une grosse ZEP, mais du coup, une branche par ZEP, pour pouvoir les intégrer une par une à la master une fois que c'est prêt.

Voilà, voilà, c'était mon avis détaillé.

Ça ne répond pas à ma question :

La question n'est pas de changer le workflow pour le moment, mais d'alléger le process.

Sur le workflow en lui même je préfèrerais qu'on en rediscute quand on aura atteint la v1, sinon ça va devenir un vrai bordel étant donné que tout le monde ne comprend déjà pas la même chose sur l'actuel, visiblement, alors qu'il est censé avoir été décidé sur ce même thread et par tout le monde.

• QA light sur les PR : les devs testent leur code avant de pusher et la PR sert juste de review rapide.

Pas particulièrement pour. D'une part parce que les devs devraient toujours faire des tests en local avant de pousser une branche (si on s'amuse a pousser des trucs pas tester on va a pas s'en sortir). Et la QA devrait continuer a être bien faite. J'ai le sentiment que ce que l'on fait en ce moment est plutôt bien, il faudrait juste plus de "couverture" de test manuel (en gros que les QA débutants soient peut être plus guides ou encourager a tester "hors champ" pour s'assurer que des effets de bord n’apparaissent pas).

Bref, pour moi on a un système de QA qui fonctionne bien. Pas forcement le plus efficace temporellement (mais hey c'est normal, on est que des bénévoles avec une vie [pro] a cote !)

Sur le workflow en lui même je préférerais qu'on en rediscute quand on aura atteint la v1

Plutôt d'accord, mais dans ce cas la on reste en freeze ?

alors qu'il est censé avoir été décidé sur ce même thread et par tout le monde.

J'ai l'impression qu'il a été discute sans que l'on puisse tout mesurer. En tout cas pour mon opinion ça me semblait une bonne idée sur le papier, mais finalement a l'utilisation je trouve ça assez lourd et compliqué tant notre code bouge rapidement.

Plutôt d'accord, mais dans ce cas la on reste en freeze ?

En théorie, non. Mais dans les faits ça ne change rien puisqu'on est en train de releaser la v1, et vu le manque d'effectifs ça revient à ignorer ce qui arrive sur dev.

Sur la QA : le process actuel duplique l'effort. Vu qu'il y a une branche et une preprod qui servent pour l'intégration, on peut imaginer une QA qui s'organise comme un pipe : une validation rapide en local pour vérifier qu'une PR ne fait pas de la merde, puis la PR est poussée vers la preprod sur laquelle une armée de testeurs qui ne se sentent pas de reconfigurer et réinstaller leur environnement toutes les 4 heures vont éplucher les fonctionnalités ensemble.

Ça ne rend pas la QA moins rigoureuse dans les faits, ça la shifte juste un peu vers la preprod, donc ça mutualise l'effort.

Mon petit doigt me dit que ça aiderait aussi à motiver les gens à faire de la QA.

La proposition de nohar fait sens je trouve… Entre la QA light pour ceux qui font de la QA régulièrement, qui permet ainsi d'accélérer les choses, puis une QA plus poussée sur la pré-prod pour les tests plus approfondis… Et pourquoi pas synchroniser régulièrement la prp avec la bdd actuelle ? Histoire d'avoir des tests avec données réelles.

Et dans ce cas comment on sais quel PR a introduit quel bug sur la preprod ? Et qui reinstall la preprod toutes les x heures ? (vrai questions hein, je ne poste pas pour raler mais je me demande juste comment améliorer le tout

Faire de la QA c'est pas la mer a boire quand tu comprends ce qui se passe et te fait tes réflexes. 80% du temps ça revient juste a créer une branche en local et faire les tests, rien de plus ni de moins. Les seules fois ou c'est tricky c'est quand les modèles de données changes parce qu'alors effectivement il faut bien nettoyer son environnement, refaire la bdd etc… (je ne parle pas des cas ou le requirement.txt change car ils sont trop rares pour être évoqués). Il y a aussi les cas ou il faut les outils front pour régénérer mais Alex est sur IRC prêt a aider pour les outils front ou envoyer un zip des ressources de la branche pour tester.
Mais sinon c'est vraiment trivial de lancer une branche pour faire un bugfix. Si tu veux un retour d’expérience de jeune testeur objectif sur "comment se passe la QA", je pense que Florian sera ravi de te répondre. Il a découvert git et django pour l'occasion et nous aider justement (son avis est "vierge de toute considération/habitude/perversion/dogme du monde professionnel ou il n'a pas encore mis les pieds).
Perso ca fait des semaines maintenant que je fais de la QA. Il me faut plus de temps a comprendre et anticiper les cas de bugs possible que de lancer la branche a tester. Et même dans le cas ou il faut tout réinstaller, une fois que tu sais qu'il y a deux dossiers a vider et le fichier de bdd a supprimer pour relancer tout de zéro (syncdb->migrate->fixtures) ca se fait en 2 minutes montre en main sur mon PC qui vieillit.

Bref, la QA c'est techniquement simple, par contre faut être capable d'anticiper la ou on risque d'avoir des cas a la con. Pour cela deux solutions : Poser des questions dans le feed de la PR en cas de doute (ou discuter sur IRC, sur le fofo etc), ou être confortable a lire du code pour anticiper les cas ou éventuellement un effet de bord peu apparaître.

du coup j'ai une feature v1 qui va arriver, je l'envoie sur master, c'est bien ça ?

Pour le moment, je ne suis plus dans le développement du site, mon avis n'est qu'un point de vue extérieur mais, si je comprends bien, initialement nous sommes censés avoir 3 branches : prod, master, dev. La prod est câblé sur la prod, le master sur la preprod et le dev est censé être utilisé par les contributeurs.

Peut-être que nous n'utilisons pas bien ce workflow. Personnellement, j'avais compris le workflow de la manière suivante : La prod est mise à jour que par des merges de la master. Le master est mis à jour par des merges de la dev et par des hotfixs (qui sont répercutés directement après sur la branche dev) et le dev est régulièrement modifié par les contributeurs.

Suis-je toujours dans le bon ?

Si oui, alors je ne vois pas pourquoi il faut changer.

• Pour les simples contributeurs, c'est complètement transparent. A la place de faire des PR sur le master, ils le font sur le dev et cas exceptionnel, pour un bug survenu sur la prod, ils font une petite modification sur le master.
• Cela peut alléger le process de la QA à la PR puisque des tests pourront être fais sur la preprod par la suite.

En espérant ne pas avoir dit des conneries.