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

En fait je pensais avoir compris :

• c'est pas bien de faire avec les dates
• on a essayé autrement mais on a pas réussi
• du coup on a préféré dire "bon bah on revient comme avant, ça marche mieux".

C'était ce que j'avais compris. Mais Spacefox, tu m'as mis un gros doute.

Par contre comme la 1.3 est annulée, quand il va falloir tester la 1.4, ça va être chaud non? Parce que là on va avoir la ZEP 3, des débuggages bien chaud, des améliorations du front etc. J'ai un peu peur que si on a manqué de ressources pour la 1.3, la 1.4 ne sera pas mieux !

Si j'ai bien compris ce que firm1 m'a expliqué en privé, en fait c'est pas ça.

firm1, tu prends 5 minutes pour remettre ce que tu m'as dit sur le ticket, ou je viole la confidentialité de la conversation pour y mettre ce que tu m'as dit ?

PS : D'accord pour la taille de la v1.4. Mais du coup on fait quoi ? On sort de la merde non testée ? On sort une release basée sur une vieille version du code, avec tous les risques de conflits que ça apporte si jamais on a la moindre correction à faire ? On bloque tout merge dès qu'on a atteint une taille critique ?

Bon la situation est un peu embêtante, parce la release est abandonnée, mais la branche est toujours là. C'est prévu dans le ZestFlow la procédure de merge des hotfix de la release dans la dev en cas d'abandon ? Faudra refaire une PR ? refaire une QA ?

Cependant, comme je le disais la dernière fois, cette release n'a pas de bug bloquant. On dirait que les bugs ont été mal interprété dans la plupart des cas.

Le problème de tri

Il y'a deux types de tri ici (qui ont été visiblement confondus) :

1. Le tri des messages sur un topic
2. Le tri des messages dans le forum

Avant, dans les 2 cas, on utilisait la date de publication pour faire le tri, sauf que dans le cas 1, ça posait des problèmes pour 2 messages postés dans la même seconde (c'était aussi ça le fameux bug des double post que l'on arrivait pas à reproduire car il fallait poster dans une seule seconde deux message). C'est la raison pour laquelle on est passé sur un tri par position là dessus.

Dans le cas 2, le tri par pubdate est justifié car il répond parfaitement au besoin (uniquement d'affichage).

Ce "bug" n'existe donc pas selon moi.

Le problème de renommage des tutoriels

Comme je l'ai dis ici, je l'ai testé et il est fonctionnel.

Le post d'Eskimon juste avant le mien dans lequel il dit avoir pété la preprod venait plutôt d'un autre souci qui n'est pas lié à la release : les images du tuto en question n'étaient pas sur le serveur de pré-production. Pour le savoir, il fallait aller lire la log renvoyer par Sentry suite à l'échec de publication. ça me semblait assez évident, mais apparemment ce n'était pas clair dans la tête de tout le monde.

Voilà, ce que j'ai comme info. Y'a encore des trucs pas clairs ? Y'a t-il une vrai raison technique pour laquelle la 1.3 n'est toujours pas en production ?

J'espère qu'on arrivera jamais là.

Et je confirme les dires de firm1, le renommage marche très bien (j'ai teste aussi) et pour la preprod casse c’était du a la publication d'un tuto dont les images étaient en prod, le script de MEP c'est alors plante sur un cas qui ne peut pas se produire en prod.

Oui, c'est prévu, c'est dans le Git Flow : les correctifs sont remontés (PR ou non selon qu'ils ont pu être testés et la facilité de leur merge).

Ça n'est pas fait tout simplement parce que je n'ai pas eu le temps de le faire…

Quant au reste, maintenant que les infos sont claires et complètes¹, et que donc j'ai une vision propre de ce qui se passe, alors en effet ça vaut probablement le coup de déployer la v1.3… Donc je vois pour la déployer ce soir.

PS : pour ceux qui se poseraient encore la question :

Une explication "claire" n'est pas une explication "longue"

Spacefox, quand le CA t'as nommé DTC, il t'a donné le droit de décider arbitrairement. On te fait confiance pour faire au mieux.

Maintenant, puisque tu poses la question, je vais te donner mon avis: je pense qu'il faut être pragmatique, et faire en fonction de nos capacités. Dire "on suspend temporairement les merges parce qu'on n'a pas le temps de tous les tester", c'est envisageable. Comme le dit Firm1, j'espère qu'on n'en arrivera pas là, car ça risque de frustrer les contributeurs. Néanmoins, si on n'a pas la capacité de tout tester, il va falloir décider de priorités, et merger le plus urgent. C'est comme ça sur tous les projets que je connais. Si tu penses que c'est trop de responsabilité pour toi d'arbitrer les priorités des merges, on trouvera une autre solution. Le fait qu'on a eu 0 DTC pendant 1 mois indique déjà que notre organisation est à améliorer. Dis toi qu'on est très heureux du travail que tu fournis, et qu'on te fait confiance si tu estimes que tel merge peut passer avec une QA plus que sommaire, mais que tel merge ne peut pas être pris pour la prochaine release parce que t'as pas assez de gens qui font de la QA et que l'autre merge est plus urgent. Laisse ton bon sens primer sur l'ordre chronologique d'arrivée des PR.

Certes, ça place une grosse confiance dans l'humain: avec ce système, tu peux laisser passer des regressions mineures en prod, retarder des merges plus que nécessaire, c'est dommage, mais, pour avancer, on ne peut pas tout faire parfaitement. Peut être même qu'un jour il y aura une régression majeure en prod. Les accidents ça arrive, ça ne tuera personne. Tant qu'on avance, on peut réparer les coquilles. Tu connais les contributeurs, tu sais qui reteste 3 fois ses commits et qui push à l'arrache, aies confiance dans les contributeurs. Là aussi, tu auras un jour ou l'autre une mauvaise surprise, mais, dans l'ensemble, ça fera gagner beaucoup de temps.

Je plussoie Natalya sur toute la ligne. Et je résumerai en deux phrase :

La communauté te fait confiance

Le mieux est l'ennemi du bien

Là où je rejoins firm1 c'est que vous avez désespérément besoin d'une solution qui vous permette de mieux suivre l'avancement de ZdS et notamment sa QA.

Une solution dans laquelle il est simple de retracer qui a fait quoi et quand, ce qui est testé et pourquoi et qui donne des informations de reporting claires sur l'état du projet pour t'aider TOI et que les autres aient également une meilleure vue d'ensemble.

Quand on bosse sur une branche c'est pas forcément évident de se rendre compte que le projet est bloqué par la QA. Si tu vois TOUS tes workflows qui passent 2h en dev, 3 semaines en attente de QA, là clairement tu as un indicateur à agiter sous le nez de tout le monde. Je pense que ça relance fortement ce sujet amené par firm1 (sur un autre topic).

Et voilà, c'est MEP (et merci à Eskimon pour son générateur de releases).

Merci pour vos retours sur le reste, je vais réfléchir à tout ça.

Merci bien

Et premier hotfix en route : https://github.com/zestedesavoir/zds-site/pull/1876

J'ai cree une branche v1.3b depuis prod puis une autre de hotfix pour y proposer ma correction (desole d'avoir fait ca en direct sur le github, mais c'est un hotfix concernant la procedure d'inscription donc urgent, et je ne peux pas faire de git sur la machine d'ou j'ecris ces lignes)

desole d'avoir fait ca en direct sur le github

Bienvenue dans mon monde

J'ai QA et mergé dans la foulée vu l'urgence. A déployer rapidement en prod

C'est exactement ce que je me suis dit "Allez, jme la joue a la firm1 ils comprendront car c'est urgent"

C'est exactement ce que je me suis dit "Allez, jme la joue a la firm1 ils comprendront car c'est urgent"

Prochaine étape, faire une MEP depuis ton smartphone

Nan chui soft moi, j'ai utilise un PC pour faire les modifs !! (en même temps avec mon vieux HTC Desire tout lent et son petit écran plein de poussière j'aurais plus risqué d'empirer le code )

Il y en a que ça ne dérange pas