Accélérer le rythme de release de ZdS

Salut Dave,

Vu le bazar qu'a été la release de la précédente version (annulation d'une release, release avec 120 tickets soit plus du double de ce qui était considéré comme "raisonnable", 4 hotfix dont un seul de sécurité) je songeais à ceci :

On pourrait par exemple imaginer avoir toujours une version en cours de release. Donc, à la mise en prod, on lancerait une nouvelle release avec ce qu'on a de déjà corrigé.

Avantages

• Releases plus petites donc risque de régression moindre
• Releases moins casse-gueules
• Moins de délais entre le développement d'une fonctionnalité attendue et sa mise en prod
• Moins de mise en prod "à l'arrache" en mode "ça fait 2 semaines que ça traîne, alors on va mettre en prod" (ce délais de 2 semaines n'est sensé être qu'un maximum

Inconvénients

• Il faut passer plus souvent sur la bêta
• C'est plus difficile (voire impossible) de faire des news sur toutes les releases – surtout que certaines ne contiendront que de petits correctifs.

Qu'en penses-tu ?

• Il faut passer plus souvent sur la bêta

Certes, mais il y a moins de choses à tester à la fois.

• C'est plus difficile (voire impossible) de faire des news sur toutes les releases – surtout que certaines ne contiendront que de petits correctifs.

Ce n'est pas un gros inconvénient. On peut remédier à ça en ayant un sujet de suvi des releases. Pour chacune :

• Date de MEP (ou : "en cours") ;
• Tickets concernés.

A cela, on ajouterait des articles (mensuels ?) récapitulatifs.

Sinon, je ne connais pas trop cet aspect, mais notre système de versions restera-t-il approprié à un tel rythme soutenu ? Faudra-t-il des noms pour chacune des releases ?

Je ne connais pas trop cet aspect, mais notre système de versions restera-t-il approprié à un tel rythme soutenu ?

Sans aucun problème.

Faudra-t-il des noms pour chacune des releases ?

Pourquoi pas – et ça ne me posera jamais souci de trouver un nom au besoin

Certes, mais il y a moins de choses à tester à la fois.

Oui mais non, normalement on test tout en mode "boite noire", pas en mode "je sais ce que je veux tester"

Pourquoi pas – et ça ne me posera jamais souci de trouver un nom au besoin

Et le jour ou tu es en vacances pendant longtemps ? ou malade ? ou que tu veux partir ? (et cela dit en passant, je trouves toujours aussi pénible le système de numérotation année.mois, il y a pas moyen de référencer proprement les releases en avance de phase…

Et le jour ou tu es en vacances pendant longtemps ? ou malade ? ou que tu veux partir ?

Bah, n'importe qui peut trouver un nom, si y'a que ça…

(et cela dit en passant, je trouves toujours aussi pénible le système de numérotation année.mois, il y a pas moyen de référencer proprement les releases en avance de phase…

Qu'est-ce que tu entends par là exactement ?

Bah, n'importe qui peut trouver un nom, si y'a que ça…

Sur la durée seul ton talent peut s'imposer !

Qu'est-ce que tu entends par là exactement ?

Par exemple dans le update.md, ont peut pas dire "pour la release xx" puisqu'on ne sais pas par avance quand sera faite la release xx, idem pour communiquer et dire "ca sera réglé dans la version xx" si on ne sait pas par avance quand ce sera fait

Ouais mais pour quoi d'autre ? La seule alternative que je vois, c'est numéroter dans l'ordre.

Moi ca me va parfaitement de faire une numérotation séquentielle, sans majeure/mineure, juste des numéros et du -RC (ou `b|c|d…)

Deux questions :

Je suis TOTALEMENT POUR un rythme de release accéléré ! Je plussoie l'idée de Vayel d'un sujet récapitulant toutes les releases.

AHMA, il faut choisir un objectif de rythme de release (1 par mois ?) ce qui permettra à Eskimon et moi de relancer les tickets bloquants avant les releases.

J'imagine que oui vu que tu proposes de procéder ainsi, mais a-t-on quelqu'un pour assurer des releases plus fréquemment ?

Perso je peux lancer les releases en préprod de temps en temps si ca aide

Comment avait été déterminé le rythme des releases à la base ? Pour des raisons particulières ?

Pour être le plus souple possible, en particulier parce que le rythme de développement est très irrégulier. C'est une release quand on pense qu'il faut en lancer une (et d'ailleurs, ça ne change pas avec ma proposition, je propose juste de changer la sensibilité de penser).

J'imagine que oui vu que tu proposes de procéder ainsi, mais a-t-on quelqu'un pour assurer des releases plus fréquemment ?

C'est plus facile de s'occuper de 2 petites releases que de trouver du temps pour en gérer une grosse.

AHMA, il faut choisir un objectif de rythme de release (1 par mois ?)

Ça n'a aucun sens pour notre projet, donc le rythme de développement est beaucoup trop irrégulier pour ça.

ce qui permettra à Eskimon et moi de relancer les tickets bloquants avant les releases.

Les tickets bloquants n'ont rien à voir avec ce rythme en fait :

• Soit il n'y a pas de release en cours de test, auquel cas "ticket bloquant" –> "Hotfix"
• Soit il y a une release en cours, et le ticket bloque la MEP de cette release, voire provoque un hotfix selon l'urgence réelle.

J'aime bien l'idée de fond (accelerer le rythme des release), mais je suis dubitatif sur l'efficacité de la méthode.

Il me semble que c'est que qu'on fait déjà. Ci je regarde un peu l'historique des releases.

• v1.6 :
  • Lancement de la release : 12 fevrier
  • MEP : 26 fevrier
  • MEP du dernier hoftix 19 mars
• v1.7:
  • Lancement de la release : 19 mars
  • MEP : 14 avril
  • MEP du dernier hotfix : 2 mai

• v15.5:

  • Lancement de la release : 20 avril
  • MEP : 4 mai
  • MEP du dernier Hotfix : 5 mai

• v15.6:

  • Lancement de la release : 12 mai
  • Puis c'était un mélange d'abandon et de corrections de bug bloquant

En gros, l'enchainement des releases c'est déjà ce qu'on fait involontairement (car à la fin d'une release de 2 semaine, la dev est souvent déjà assez pleine pour en relancer une autre), et ça n'a pas l'air de trop marcher. De plus, lorsqu'on a des bugs bloquants (comme ça a souvent été le cas) sur la dev, on ne peut pas vraiment lancer de release car ça duplique les efforts (on va corriger la release et pendant ce temps le problème traine sur la dev, etc.).

Attention, tu confonds 2 trucs dans ton listing : la MEP d'une version et la MEP d'un hotfix sur cette version. On a lancé pas mal de hotfix justement pour ne pas avoir à attendre la release suivante, parce qu'il n'y avait pas de quoi lancer une release complète.

En réalité on était loin de ma proposition, puisqu'on a eu :

• v1.6, MEP le 26/02 –> v1.7, lancement le 02/04¹ : 35 jours
• v1.7, MEP le 14/04¹ –> v15.5, lancement le 20/04 : 6 jours
• v15.5, MEP le 04/05¹ –> v15.6, lancement le 12/05 : 11 jours

Il ne faut pas oublier non plus que le développement a été plus rapide en avril/mai que maintenant, et qu'on a eu des releases énormes avec tous les problèmes qu'on connaît.

Maintenant si tu as une idée plus intelligente, je suis preneur. Mais le fait est que le rythme actuel, on l'a constaté sur les dernières releases, ne fonctionne pas.

en effet, il faudrait presque que lancer une version = lancer une release, peu importe la quantité de travail mergé.

On a lancé pas mal de hotfix justement pour ne pas avoir à attendre la release suivante, parce qu'il n'y avait pas de quoi lancer une release complète.

Le façon de traiter les hotfix de prod actuelle ressemble très fortement à un cycle de release normale. On crée une branche de hotfix dérivée de la prod, on la corrige et on merge. On peut donc voir la gestion des hotfix de prod comme une mini-release, mais appliquée à la prod.

Tout ça pour dire qu'en enchainant les releases, on risque de se retrouver avec 2 releases en cours. La release normale, et la mini-release qui sert à corrigée les bugs bloquants de la branche de prod.

Dans l'absolu, pour accélérer le rythme, j'aurai tendance à me rapprocher d'une démarche Continuous Delivery en mettant l'accent sur les tests d'intégrations et revue de code ce qui permettrait de gagner en qualité et donc de pouvoir réduire le délai des deux semaines.

Tout ça pour dire qu'en enchainant les releases, on risque de se retrouver avec 2 releases en cours. La release normale, et la mini-release qui sert à corrigée les bugs bloquants de la branche de prod.

Oui, et ? C'est le principe d'un hotfix. Ce n'est pas "un risque", c'est juste le fonctionnement normal du truc. Je ne comprends vraiment pas où tu veux en venir ici.

Là ou je veux en venir c'est qu'en ayant deux releases en parallèle, et étant donné qu'il y'en a une qui est prioritaire (celle du hotfix), on se concentre nécessairement sur cette dernière. Ce qui fait qu'on s’intéresse moins à l'autre release en cours (et donc qu'elle est moins bien testée, voire pas du tout si le hotfix dure trop longtemps). Le risque est donc d'avoir beaucoup de plus de regressions en prod car on a pas eu le temps de tester en preprod, car on était occupé avec les hotfix.

Un hotfix, c'est uniquement s'il y a un problème bloquant sur la prod qui ne peut pas attendre la livraison suivante.

1. Ils doivent donc être exceptionnels. La moitié de ceux qu'on a eu depuis la v1.0, c'était juste des MAJ de sécurité de Django ou autre. Autant dire que c'est pas avec ça qu'on va être "occupé"
2. En resserrant le rythme des releases, tu réduis mathématiquement le nombre de hotfixes, puisque pas mal de problèmes autres se retrouvent à pouvoir attendre la release suivante qui vient dans les 2 semaines – c'est par exemple le cas de beaucoup des hotfix hors sécurité récents
3. Un hotfix, par définition, ça doit être simple et court. Normalement, seules 2 personnes sont concernées par un hotfix (avant sa MEP) : le développeur et le gars qui fait la QA. Et les deux doivent être faits rapidement.
4. Donc, si on a un problème de concentration et de baisse de qualité de la bêta suite à des hotfix, c'est que tu as des problèmes beaucoup, beaucoup plus graves que ce dont on est en train de parler.

Le problème ici, c'est que la notion de hotfix que tu décris est très théorique. Dans la pratique, après 1 an, et 11 releases on remarque que la théorie ne s'applique malheureusement pas chez nous (ce qui est normal dans un projet bénévole comme le notre).

Comme on le voit dans ce tableau, la procédure de hotfix chez nous prend tout de même du temps. Si on avait une release en parallèle, je ne pense pas que ça améliorerait les choses (n'oublions pas le fameux délai de 2 semaines de vie d'une release).

De plus dans le cas de ZdS, n'oublions pas qu'on a pas de ressources infinies. Et donc mobiliser 1 dev + 1 testeur + 1 deployeur pour assurer le hotfix complet n'est pas toujours évident.

Durée entre la MEP et le dernier Hotfix

Je le répète : cette durée n'a aucun sens. Le hotfix peut arriver n'importe quand, en particulier parce que beaucoup sont des problèmes de sécurité (qu'ils touchent le code du site ou non).

Comme on le voit dans ce tableau, la procédure de hotfix chez nous prend tout de même du temps.

Non, ce tableau ne montre absolument pas cette donnée. Parce "hotfix" != "mauvaise qualité du code livré". Beaucoup sont des problèmes de sécurité, qui arrivent n'importe quand.

La seule chose qu'on peut dire quant à nos hotfix, c'est qu'on a trop de hotfix qui proviennent de problèmes de code chez nous, parce qu'on en a un nombre > 0.

PS : C'est mon dernier message sur le "problème des hotfix". Je ne veux pas perdre plus de temps que je n'ai pas sur ce non-sujet.