Accélérer le rythme de release de ZdS

Pour éviter les releases gigantesques

L'auteur de ce sujet a trouvé une solution à son problème.
Staff
Auteur du sujet

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 :

Est-ce qu'on ne ferait pas mieux d'accélérer le rythme de release ? (et donc d'avoir des releases beaucoup plus petites).

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 ?

Édité par SpaceFox

  • 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 ?

Édité par Vayel

+0 -0

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…

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+4 -0
Staff
Auteur du sujet

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 ! :D

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

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+1 -0

Deux questions :

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

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 ?

Édité par Vayel

+0 -0

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.

Médicament flemmard aux pul(p)sions imprécises. “Don’t wait for the perfect moment. Take the moment and make it perfect.”

+0 -0
Staff
Auteur du sujet

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.
Staff

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

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é.

SpaceFox

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

  • v1.6 :
  • v1.7:
  • v15.5:

  • 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.).

Staff
Auteur du sujet

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/041 : 35 jours
  • v1.7, MEP le 14/041 –> v15.5, lancement le 20/04 : 6 jours
  • v15.5, MEP le 04/051 –> 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.


  1. La version tagguée `v1.7-RC1 de déployait pas, cf le topic à ce sujet. Et donc ne constitue pas le lancement de la release. 

Staff

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.

Staff
Auteur du sujet

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.

Staff

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.

Staff
Auteur du sujet

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.
Staff

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).

Release Nombre de hotifx Durée entre la MEP et le dernier Hotfix
1.0 1 3 jours
1.1 1 6 jours
1.2 1 5 jours
1.3 1 6 jours
1.4 2 24 jours
1.5 0 0 jours
1.6 2 21 jours
1.7 2 17 jours
15.5 1 1 jour
15.6 1 9 jours

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.

Staff
Auteur du sujet

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.

Édité par SpaceFox

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte