Préparation du déploiement de la v1.3

J'ajouterai que pour l'instant aucun test des modifications faites sur les tutos n'a été fait sur la preprod.

J'ai mis le tuto arduino en validation sur la preprod, il faut que quelqu'un le valide pour qu'on puisse tester :

• l'envoie du mp à tous les auteurs
• le renommage par la suite

Voilà.

J'ai teste le renommage et c’était tout bon.

sur un tuto aussi gros? (et qui se rapproche du cas réel !)

Il faut tester le renommage des parties et aussi du tuto en entier

LoL j'ai pété la preprod en le validant (mais sentry l'a bien pris )

ah ah

J'ai testé le renommage d'un tutoriel, c'est bon.

J'ai testé la feature ci-dessous, elle est trop coule.

LoL j'ai pété la preprod en le validant (mais sentry l'a bien pris )

Bon bah, ça risque pas de passer tout ça

J'ai testé la feature ci-dessous, elle est trop coule.

Inutile donc indispensable !

Je la trouve super utile. Grâce à ça tu reconnais les bot, tu sais quel est le meilleur moment pour retrouver quelqu'un, etc.

Aaaahhh, je veux être staff du coup.

firm1 est donc quelqu'un de matinal, il allume son ordinateur à 7h et traite ses messages. Le soir, pas d'excès, dodo à 21h. Il passe son samedi à l'atelier macramé de son village. Dimanche matin, grasse mat' et l'après midi, match de foot avec l'équipe B de son village. J'ai tout juste ?

Tu as bon pour le profilage, mais tu as mauvais sur le pseudo de la personne.

Du coup je te laisse deviner, qui s'est ?

Moi je suis plutôt du genre "tard le soir" et "tot le matin"

Si on parle juste du graphique, c'est pas impossible que ce soit moi. Si on parle du profile, c'est impossible, tu me vois faire du sport?

@artragis, non toi tu est plutot du style régulier sur la semaine. Cf. le screen ci-dessous.

sympa par contre y'a forcément une heure de décallage, j'ai des pics d'activités à des moments où je ne suis pas devant l'ordi…

Yep je confirme l'heure de décalage

Abandon de la mise en production de la v1.3

Statut

Comme je m'y attendais un peu, on a pas vraiment avancé ici. Le délais prévu pour tester une release étant dépassé, et la branche de dev avançant à grande vitesse, on ne peut pas se permettre de laisser traîner la v1.3 sans la clôturer. D'ailleurs, la branche de release ne peut déjà plus être mergée automatiquement dans dev.

La version v1.3 est donc officiellement abandonnée.

Et maintenant ?

1. Merger les correctifs de release dans dev
2. Fermer cette release
3. Relancer une procédure de release sur une nouvelle v1.3 (sans doute appelée v1.4, je n'ai encore rien décidé à ce sujet), à partir d'une version actuelle de dev.

Analyse post-mortem

Pourquoi a-t-on abandonné cette release ?

Deux facteurs principaux :

1. Comme prévu, j'ai levé le pied en novembre, donc je n'ai pas pu suivre cette release, et donc aucun suivi complet n'a été fait
2. On a toujours un bug bloquant après 2 semaines de tests

Sur un sujet plus positif, la communication autour de la release a l'air d'avoir ramené pas mal de monde ; même si la majorité des bugs découverts sont hors du domaine de la release.

Concernant le manque de suivi

Le fait que je lève le pied en novembre était prévu de longue date, et normalement connu.

J'avais quand même pris le temps de lancer la release pour 2 raisons (toutes deux liées au rythme de développement en fait) :

1. La release devenait très grosse, il était temps de lancer quelque chose
2. Le rythme très élevé de développement me laissait penser qu'on aurait de quoi faire le suivi

Concernant le point 1, je reste persuadé que c'était la chose à faire : on s'est déjà cassé les dents sur une release énorme et horrible à tester, au début.

Concernant le point 2, j'ai clairement fait l'erreur de ne pas être plus clair sur mon manque de disponibilité et de ne pas avoir demandé explicitement à quelqu'un de suivre cette release.

Cela dit, je reste dubitatif sur le fait que si le développement a continué à un rythme ultra soutenu pendant ces 2 semaines (ce qui est génial), presque personne ne semble s'être inquiété du sort de la release (ce qui est dommage).

Concernant le bug bloquant

Si je déploie aujourd'hui, je n'ai aucun comportement clair sur l'ordre des topics et des forums. Le bug ne sera résolu que lorsqu'on aura un comportement défini et fiable là-dessus. Et aucune release ne pourra être lancée tant qu'il reste un bug bloquant.

Ce qui me chagrine ici, c'est qu'on a visiblement confondu vitesse et précipitation, ce qui a entraîné des situations bordéliques et ce fameux bug.

D'ailleurs, j'en profite pour rappeler ici une règle simple :

Il est absolument interdit de merger son propre code. Même s'il vous paraît inoffensif.

Les deux seules exceptions tolérées sont :

1. Le cas d'un hotfix de production
2. Un code qui ne touche que de la documentation ou des commentaires. Et encore, là vous devez laisser le temps aux autres développeurs de le commenter au besoin.

Que faire pour éviter un nouvel échec

Voici ce que je propose :

1. Avoir un "responsable de release", quelqu'un qui a le temps, sur les 2 semaines de release, de s'assurer que la release est un minimum testée.
2. Dès que la release est correctement testée, on la déploie. On a absolument pas besoin d'attendre la dernière minute pour ça : si d'évidence tout marche après 1 semaine de tests, allons-y !
3. Toute autre bonne idée est la bienvenue…

Je suis également pour que toutes les QA des PR soient reprises et testées sur la preprod. Ça permettra une double sécurité.

Je l'ai pourtant répété nombre de fois sur l'issue en question. le "bug bloquant" n'existe pas. Pour la simple et bonne raison qu'il a été corrigé/hotfixé par gustavi depuis 1 semaine. L'issue a visiblement été ré-ouverte pourtant, une fois le fotfix déployé en préprod, on constate bien que le bug est corrigé. Donc je rejoins donc la résolution :

Je l'appuierai en disant, qu'il faut impérativement que celui qui lance la release (et fait donc le déploiement en préprod) ait de la disponibilité pour suivre cette release. Lancer la release ce n'est pas juste faire les tag et déployer. Il faut bien évidemment suivre pour que dès qu'on a un hotfix mergé, on le déploie en préprod.

Le chargé de suivi de release peut être n'importe quel développeur avec les droits suffisants. Mais étant donné que c'est le DTC qui prend la décision de valider ou d'abandonner la release au final, il est impératif que ce dernier ait un le regard pas trop éloigné, pour pas que les devs se retrouve à devoir faire un résumé de ce qui s'est passé. Là on s'est retrouvé avec 0 DTC pendant deux semaines, ça ne pouvait pas marcher. Il faut trouver un backup à SpaceFox quand il est pas dispo.

Le but initial de ce topic était bien de s'organiser pour savoir s'il faut lancer une release et quand ? et est-ce qu'on a les ressources disponibles pour ça. ça ne sert à rien de lancer une release si on a pas les ressources disponibles pour s'en occuper (on a fait la même erreur pour la 1.2 poutant), vaut mieux attendre que de se lancer avec l'assurance de se vautrer par la suite. Les ressources pour une releases sont :

• les testeurs (il y'en a eu pas mal en préprod, et ça c'était cool)
• un gestionnaire de release : qui lance la release, vérifie s'il y'a des bug bloquants issues de la release et les communique au plus tot, suit et déploie les hotfix quand ils sont mergés le plus tôt possible.
• un gestionnaire de ticket de la release : qui repporte sur github les bugs liés à la release en cours (ça peut être fait par le gestionnaire de release mais aussi par n'importe quel dev qui a les droits suffisants)
• un DTC : qui suit particulièrement l'état des tickets de release.

Notons que (oui je reviens à a charge) : bon nombre des problèmes exposés ici, si on avait un outil comme JIRA, ça aurait résolu pas mal de soucis (une vue "état de la release", attribution de tache "MEPP" à quelqu'un, etc.)

Voilà un peu ce que je pensais de tout ça.

Je l'ai pourtant répété nombre de fois sur l'issue en question. le "bug bloquant" n'existe pas. Pour la simple et bonne raison qu'il a été corrigé/hotfixé par gustavi depuis 1 semaine. L'issue a visiblement été ré-ouverte pourtant, une fois le fotfix déployé en préprod, on constate bien que le bug est corrigé.

Une bonne fois pour toute : je n'ai toujours pas de réponse claire à ce problème. J'ai toujours un bug, qui n'est toujours pas résolu.

J'ai créé une issue spécifique pour ce sujet avec tous les détails.

Le but initial de ce topic était bien de s'organiser pour savoir s'il faut lancer une release et quand ? et est-ce qu'on a les ressources disponibles pour ça. ça ne sert à rien de lancer une release si on a pas les ressources disponibles pour s'en occuper (on a fait la même erreur pour la 1.2 poutant), vaut mieux attendre que de se lancer avec l'assurance de se vautrer par la suite.

Sauf que comme on l'a déjà vu, attendre trop longtemps c'est se retrouver avec une release géante, ce qui est aussi l'assurance de se planter et on en a déjà fait l'expérience.

J'en déduis donc que la seule solution, quand on commence à avoir beaucoup de contenu dans une release, c'est de bloquer tout merge jusqu'à ce que quelqu'un soit disponible pour faire une release.

Quant au débat sur les outils, pour moi il est complètement hors sujet : on a eu personne pour superviser la release, et surtout on a eu personne pour s'inquiéter du sort de la release. C'est pas des outils qui vont nous aider à ça.

PS :

Là on s'est retrouvé avec 0 DTC pendant deux semaines

Non. On s'est retrouvé sans DTC pendant un mois.

Une bonne fois pour toute : je n'ai toujours pas de réponse claire à ce problème. J'ai toujours un bug, qui n'est toujours pas résolu.

Bon bah perso j'abandonne.

Si un dev se sent de faire l'explication …