Proposition : workflow de releases

Bonjour tout le monde,

Maintenant qu'on a un site ouvert au public, on va devoir songer à mettre en place un système de mise à jour du site qui réponde à nos nouvelles contraintes :

• Fiable. On a déjà expérimenté la mise en prod qui provoque plein de régressions, l'idéal serait qu'elle ne revienne pas.
• Invisible pour les membres ou presque, en terme de coupure d'accès.

Un peu de contexte

On ne s'en rends peut-être pas compte, mais on a déjà un site qui a une activité certaine. Deux jours après l'ouverture publique, bien qu'en bêta, on ne peut pas se permettre de gérer le site comme un petit blog personnel.

Actuellement, Zeste de Savoir, c'est :

• 250 inscrits
• 36 000 pages vues depuis l'ouverture publique
• 6/8 membres présents en permanence sur le site la journée
• Plus d'un hit/seconde en permanence sur notre Nginx la journée

Alors certes, on a un beau potentiel de croissance, mais on est déjà loin au-dessus des 20 visites / jour qui font la joie du blogueur amateur !

De plus, pour des raisons historiques, la majorité de nos visiteurs ont conscience des problèmes de qualité, de releases-à-régressions et de prod HS. Et ils nous le font savoir.

Exemple : hier je mettais en place une surveillance de Gunicorn. Un truc qui aurait dû couper le serveur pendant 2 secondes, mais qui n'a pas marché du premier coup suite à un problème de configuration entre la préprod et la prod. Ça a coupé le serveur pendant 2x 2 minutes, et 1x 2 secondes ensuite.

Eh bien en moins de 5 minutes de coupures cumulées, et alors qu'on est encore en bêta, on a eu un rapport de bug de plusieurs personnes et une taquinerie sur Twitter.

Workflow proposé

Worflows valables sauf hotfix urgents, évidemment.

Général (après la v1.0)

À un moment M, on décide qu'on a suffisamment de matière pour mettre en production quelque chose, i.e. faire une version N Dès lors :

1. On gèle l'ensemble des fonctionnalités à mettre en prod, c'est-à-dire qu'on merge dev sur master, notre branche de release.
2. La branche de relase ne reçoit plus que des correctifs. Les nouvelles fonctionnalités seront sur la version N+1 et vont sur dev.
3. La pré-prod est mise à jour avec master aussi souvent que nécessaire. On vérifie sur la préprod, et pendant un temps suffisamment long, que tout fonctionne correctement, que les détails sont là, qu'on a rien oublié et qu'on a rien cassé.
   Ceci n'est pas redondant avec la QA, parce que là on teste bien l'ensemble du site et non une fonctionnalité précise.
   On pourrait imaginer ouvrir cette pré-production à des personnes tierces, selon les besoins.
4. Une fois qu'on ne trouve plus de problèmes sur la pré-prod, on met en prod, ce qui implique 3 sous-étapes :
   1. On taggue la version qui va en prod.
   2. On merge master dans prod (logique) mais aussi dans dev (pour faire remonter les corrections suite aux tests en pré-prod)
   3. On fait la MEP proprement dite.
5. C'est prêt, on communique sur les nouvelles fonctionnalités !

Adaptation pour la bêta publique

Pour l'instant on est en bêta publique, ce qui implique qu'on a beaucoup de travail à faire et des membres qui sont – j'espère ! – prêts à être plus tolérants avec les trucs bizarres sur le site. Ce qui ne nous autorise pas à faire n'importe quoi.

Pour essayer de faire le tri dans tout ça, on a présentement 4 milestones :

1. Version RCx : les trucs à faire le plus vite possible et à mettre en production rapidement.
2. Version 1.0 : les trucs à faire pour la v1.0, i.e. le 21 juillet.
3. Version 1.x : les trucs qui peuvent attendre après la sortie de la v1.0, mais qu'il ne faudra pas trop trop tarder à faire.
4. Version 2.x : les lettres au Père Noël, qui regroupent des tas de bonnes idées mais absolument pas prioritaires.

Au niveau des mises en prod elles-mêmes, la milestone RCx a une date pour ce WE, ce qui ne veut pas dire qu'il faut attendre ce WE pour mettre en prod.

Voici ce que je propose :

• Une mise en prod rapide, au moins pour gérer les bugs qui nous sont remontés mais qui sont déjà corrigés.
• Une mise en prod tous les 2 à 3 jours, en passant par la pré-prod à chaque fois, pour nous garantir un minimum de stabilité dans ce qu'on diffuse. Parce que c'est le rush, le moment où tout le monde développe très vite, et que c'est exactement à ce moment qu'on a tendance à oublier des cas pathologiques.

Concernant la gestion de ces MEP, on allègerais aussi :

• Pas de merges.
• Un tag à chaque mise en prod, à la fois pour savoir ce qui est vraiment parti en prod (ça peut servir pour comprendre un bug) et pour afficher un numéro de version lisible à nos utilisateurs.

Qu'en pensez-vous ?

Ça me va parfaitement. Merci d'avoir pris le temps de faire ce thread !

I'm agree ! On signe où ?

J'aime bien vous taquiner sur Twitter ! \o/
(en vrai je taquine tout le monde, c'est mon petit plaisir)

Sinon, je compte me mettre à Python dès que j'aurai un peu de temps. Vous avez des tutos à me conseiller ? Je connais déjà (et suis) Sam & Max, mais pas vraiment pour la partie Python, que j'ai du mal à comprendre du haut de mes connaissances en PHP et JS.

Une fois que j'aurai compris comment ça marche, je pourrai sans doute vous filer un coup de main (après l'été je pense, vu les projets qui devraient me tomber dessus dans les jours à venir)…

À part ça, le workflow me paraît cohérent, mais je me demande si vous comptez fixer une routine de mise en prod ou si on aura des mises à jour qu'une fois que tout est fait (j'ai pas encore remarqué de MAJ depuis le début de la bêta) ?

P.S. : @Alex-D : on dit "I agree" en bon franglais

j'ai pas encore remarqué de MAJ depuis le début de la bêta

Il y en a déjà eu pourtant, pour des corrections de bugs plus particulièrement. Tu as le hash git en bas avec le tag de version actuel

Correction : de MAJ majeure ou visible

J'ai bien vu que les erreurs 500 étaient corrigées et quelques autres trucs discrets, mais j'ai l'impression de le tag de version a pas changé depuis 2 jours…

Enfin, je vous mets pas la pression, je sais bien que vous avez un boulot et que vous faites de votre mieux.

Ha oui de toute façon il n'aura que des corrections de bugs jusqu'à fin juillet. Pour le reste, il y a des trucs en attentes mais aucun des admins dispo ces derniers jours pour faire une mise en prod propre, du coup c'est en attente.

Merci pour la proposition, certains point restent flous

On merge master dans prod (logique) mais aussi dans dev (pour faire remonter les corrections suite aux tests en pré-prod)

Le merge d'une branche de release vers une branche de dev (qui a potentiellement reçu des evols) n'est pas anodin. On peut avoir de gros conflits. Comment se passe la QA a ce niveau ?

Autre chose aussi, un tag pour chaque MEP, je trouve ça un peu lourd. On fait du site web, donc je préfère un tag pour les grosse versions (1.0, 1.1, 1.15, 2.0, etc). On a déjà dans le footer le hash unique correspondant a la situation de la version en production, si on doit rajouter un nouveau Tag toutes les 10 PR, on risque de se retrouver avec une flopée de tags.

Théoriquement, comme master ne reçoit que des correctifs, on ne devrait pas avoir de gros conflits.

Maintenant, ça c'est la théorie.

La pratique c'est que ça arrivera. Dans ce cas je propose de faire une PR du merge et de le traiter comme une PR normale.

Je ne comprends pas cette remarque.

Qu'entends-tu par "faire du site web" ? Est-ce que pour toi ça sous-entends faire plus d'une mise en production par semaine une fois la bêta finie ?

Le tag a vocation à deux choses :

1. Indiquer aux visiteurs sur quelle version ils en sont (pour les rapports de bug)
2. Pouvoir récupérer instantanément la version problématique en prod, que ce soit l'actuelle ou une vieille.

Il prends environ 5 secondes à créer, et il n'y a aucun problème à en avoir 377. Et au pire on peut nettoyer les plus vieux.

Le but du workflow proposé est d'assurer une certaine qualité, et donc de tester en préprod. Ce qui implique de ne pas mettre en prod trop souvent.

Là au début, forcément ça va aller vite, parce qu'on aura plein de bugs à corriger en particulier.

Mais si en rythme de croisière on arrive à une MEP digne de ce nom toutes les deux semaines, ce qui serait déjà un bon rythme, ça ne fait qu'une vingtaine de tags par an.

Pour moi le danger des MEP trop fréquentes, c'est de rogner sur les tests et la qualité. Non seulement ce n'est pas ce qu'on veut, mais en plus l'expérience prouve qu'il vaut mieux diminuer le rythme de livraison et assurer les tests. Et ceci est valable aussi sur un site web : on l'a tous vécu sur au moins un site ; et c'est valable dans le monde professionnel (pas plus tard que ce matin, un client a annulé une MEP parce qu'ils ont découvert un bug à la dernière minute, eux aussi voulaient livrer le plus vite possible).

Il prends environ 5 secondes à créer, et il n'y a aucun problème à en avoir 377. Et au pire on peut nettoyer les plus vieux.

377 on ne sait pas, 378 ne semble par contre pas posé de problèmes.

Je suis pas contre le tag à abus.

Par contre, pour les merges à répétition… Je trouve ça juste pas propre. Mais alors pas propre du tout. C'est un gros risque à gros bordel en fait. Non, je ne vais pas parler de rebase (je vois déjà les poils du renard se hérisser).

En fait, puisque master part systématiquement de dev (et prod de master), lorsqu'on fait une PR de fixe - hotfix urgent ==> prod, hotfix pour la release ==> master, autre ==> dev), il faut alors répercuter le tout. En somme, si je fais un hotfix urgent, à destination de prod donc, il faut alors le merger individuellement dans prod, master, et dev. Si c'est un hotfix de release, il faut alors le merger individuellement dans master et dev. Ainsi de suite.

Ca nous permettra d'avoir des branches ISO et mises à jour en permanence. Alors que si on fait comme tu le suggères, soit en mergeant une fois le process fini, ceux qui sont parti sur une branche plus en dessous n'auront pas forcément le fix proposé… Parfois, essaieront aussi de bricoler un truc pour fixer quelque chose de dérangeant, qui aurait pu être fixé en amont. Ce qui amène des conflits. Et donc des emmerdes.

Thoughts ?

Pour une fois, le Git Flow ne nous aide pas sur la question puisqu'il précise que les deux sont possibles :

Le vrai problème est un problème de ressources : est-ce que ça va être gérable, vu l'équipe qu'on a, de se faire un double merge à chaque PR ?

Pour les hotfix en prod, la question ne se pose pas en fait : ils sont tous individuels.

Le vrai problème est un problème de ressources : est-ce que ça va être gérable, vu l'équipe qu'on a, de se faire un double merge à chaque PR ?

Je ne vois qu'un moyen de trancher : essayer. Pendant ce temps, recruter. Une fois que les nouvelles recrues ont atteint un rythme de croisière, aviser.

Justement, d'où ma volonté au départ de n'accorder les droits de merge qu'a un nombre limité de décideur. Qui lui saura faire ce qu'il faut.

Oui, mais faut quand même les répercuter sur les branches d'en dessous, non ? Surtout si on veut pas faire de rebase.

Justement, d'où ma volonté au départ de n'accorder les droits de merge qu'a un nombre limité de décideur. Qui lui saura faire ce qu'il faut.

C'est encore pire à mon sens : on va dépendre des disponibilités d'un tout petit nombre de personnes pour avancer.

Oui, mais faut quand même les répercuter sur les branches d'en dessous, non ? Surtout si on veut pas faire de rebase.

Certes mais il n'y a plus les problèmes que tu décrivais de bugs qui trainent alors qu'ils sont déjà corrigés par ailleurs parce qu'on attend une date X pour merger.

Honnêtement je trouve que y'a peu de chance que le comité en entier soit absent. C'est hyper bien géré pour les gros projets open source, pourquoi ça ne pourrait pas l'être pour le notre, qui est plus petit ?

Et ce que j'appelle par "les branches d'en dessous", c'est dans la hirérachie principale (soit les 3 branches principales : prod, master, et dev), sachant qu'en fait, on a cette relation :

1
2
3

     /- prod
   /--master
------dev

Donc, il est logique que si un merge arrive sur prod, alors on doit le répercuter les autres branches. Comme ça y'aura un fix qui arrivera partout. Pas que sur une seule branche. Si quelqu'un développe sur sa branche, qu'il voit le bug alors qu'il a peut-être été fixé dans une des branches principales… Alors il l'aura son fix dans les trois branches principales. C'est de la pure synchro.

Si on attend un process de release pour faire toutes les opérations de merge, le bug pourra toujours courir avant que la dite release soit faite. Ce genre de schéma permet une grande souplesse. Vous qui citez régulièrement le git flow, vous verrez que sur la branche release, dès que 'ya un bug fixe… Il est mergé à la fois sur la branche de dev et celle de prod ! Une branche n'a pas vocation à être mergée dans une seule branche ! Elle peut être mergée dans plusieurs branches à la fois…

Ce genre de manipulations nous permettra d'avoir 3 branches distinctes et indépendantes au final. Plutôt que d'attendre en permanence de faire des merge inceste entre celles-ci, qui en plus de rendre l'historique peu claire, nous prendra la tête avec des conflits qui seront plus présent que dans la manip que je décris ici.

J'émets une réserve : compte le nombre de contributeurs actuellement présents et dispos en date. Et la semaine dernière.

Tant qu'on n'aura pas recruté/rameuté plus de monde, le nombre de contributeurs que nous sommes, sachant que tout le monde est bénévole, est un réel handicap.

Ce qui nous manquait la semaine dernière, c'était la QA en fait. Niveau "merger", on avait ce qu'il faut, soit victor par exemple.

Non, il ne manquait pas que de la QA. À l'heure actuelle, le besoin de contributeurs techniques est à la fois global et critique.

Si on a vraiment assez de gens dans ce comité pour être sûr à 150% qu'il y aura en permanence quelqu'un dispo pour faire le job, alors OK. Dans le cas contraire, c'est un problème qu'il faut régler avant de fonctionner comme ça.

Moi je suis prêt à tester en tout cas. Par contre, n'ayant pas tellement de connaissance dans le code (voir pas du tout en fait), je peux m'occuper que du merge.

Pour tester (QA) tu as juste besoin de savoir utiliser le site.