Derniers messages sur Zeste de Savoirhttps://zestedesavoir.com/forums/2014-12-09T10:11:06+01:00Les derniers messages parus sur le forum de Zeste de Savoir.Préparation du déploiement de la v1.3, message #333152014-12-09T10:11:06+01:00Natalya/@Natalyahttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33315<p>Il y en a que ça ne dérange pas <img alt=";)" src="/static/smileys/clin.png"></p>Préparation du déploiement de la v1.3, message #333082014-12-09T09:58:58+01:00Eskimon/@Eskimonhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33308<p>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 <img alt=":D" src="/static/smileys/heureux.png"> )</p>Préparation du déploiement de la v1.3, message #333022014-12-09T09:52:56+01:00Kje/@Kjehttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33302<blockquote>
<p><img alt=":D" src="/static/smileys/heureux.png"> C'est exactement ce que je me suis dit "Allez, jme la joue a la firm1 ils comprendront car c'est urgent" <img alt=":D" src="/static/smileys/heureux.png"></p>
</blockquote>
<p>Prochaine étape, faire une MEP depuis ton smartphone <img alt=":-°" src="/static/smileys/siffle.png"></p>Préparation du déploiement de la v1.3, message #332972014-12-09T09:46:13+01:00Eskimon/@Eskimonhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33297<figure><blockquote>
<blockquote>
<p>desole d'avoir fait ca en direct sur le github</p>
</blockquote>
<p>Bienvenue dans mon monde <img alt=":)" src="/static/smileys/smile.png"></p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33295">firm1</a></p></figcaption></figure><p><img alt=":D" src="/static/smileys/heureux.png"> C'est exactement ce que je me suis dit "Allez, jme la joue a la firm1 ils comprendront car c'est urgent" <img alt=":D" src="/static/smileys/heureux.png"></p>Préparation du déploiement de la v1.3, message #332952014-12-09T09:43:40+01:00firm1/@firm1https://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33295<blockquote>
<p>desole d'avoir fait ca en direct sur le github</p>
</blockquote>
<p>Bienvenue dans mon monde <img alt=":)" src="/static/smileys/smile.png"></p>
<p>J'ai QA et mergé dans la foulée vu l'urgence. A déployer rapidement en prod</p>Préparation du déploiement de la v1.3, message #332782014-12-09T08:25:32+01:00Eskimon/@Eskimonhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33278<p>Et premier hotfix en route : <a href="https://github.com/zestedesavoir/zds-site/pull/1876">https://github.com/zestedesavoir/zds-site/pull/1876</a></p>
<p>J'ai cree une branche <code>v1.3b</code> depuis <code>prod</code> 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)</p>Préparation du déploiement de la v1.3, message #332762014-12-09T08:08:59+01:00elyppire/@elyppirehttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33276<p>Merci bien <img alt=":)" src="/static/smileys/smile.png"></p>Préparation du déploiement de la v1.3, message #332712014-12-08T23:59:38+01:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33271<p><a href="https://github.com/zestedesavoir/zds-site/releases/tag/v1.3">Et voilà, c'est MEP</a> (et merci à Eskimon pour son générateur de releases).</p>
<p>Merci pour vos retours sur le reste, je vais réfléchir à tout ça.</p>Préparation du déploiement de la v1.3, message #331872014-12-08T17:10:28+01:00Javier/@Javierhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33187<p>Je plussoie Natalya sur toute la ligne. Et je résumerai en deux phrase : </p>
<blockquote>
<p>La communauté te fait confiance</p>
<p>Le mieux est l'ennemi du bien</p>
</blockquote>
<p>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.</p>
<p>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.</p>
<p>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).</p>Préparation du déploiement de la v1.3, message #331512014-12-08T14:34:09+01:00Natalya/@Natalyahttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33151<p>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.</p>
<p>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.</p>
<p>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.</p>Préparation du déploiement de la v1.3, message #331422014-12-08T14:06:57+01:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33142<figure><blockquote>
<p>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 ?
</p>
</blockquote>
<figcaption><p><a href="http://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33118">firm1</a></p></figcaption></figure><p>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).</p>
<p>Ça n'est pas fait tout simplement parce que je n'ai pas eu le temps de le faire…</p>
<p>Quant au reste, maintenant que les infos sont <em>claires</em> et <em>complètes</em><sup id="fnref-recueil"><a class="footnote-ref" href="#fn-recueil">1</a></sup>, 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.</p>
<p>PS : pour ceux qui se poseraient encore la question :</p>
<p><strong>Une explication "claire" n'est pas une explication "longue"</strong></p>
<div class="footnote">
<hr>
<ol>
<li id="fn-recueil">
<p>À ce sujet : c'est à la personne qui teste ou qui découvre un bug d'expliquer le problème, pas aux développeurs ou à quiconque d'autre d'aller chercher les informations<sup id="fnref-exemple"><a class="footnote-ref" href="#fn-exemple">2</a></sup>. Sauf si cette personne <em>n'est pas en mesure</em> d'aller chercher lesdites informations, bien entendu. C'est une question basique d'efficacité, et l'une des règles de base du report de bugs. La personne qui trouve un problème sait ce qu'elle a testé, ce qu'elle a obtenu et ce qu'elle s'attendait à obtenir. Tout autre personne ne peut que le deviner, avec les pertes de temps et les incompréhensions qui en découlent. <a class="footnote-backref" href="#fnref-recueil" title="Retourner au texte de la note 1">↩</a></p>
</li>
<li id="fn-exemple">
<p>Exemple ici, la dernière info que j'ai à propos du renommage de tuto dit très exactement "Bon bah, ça risque pas de passer tout ça <img alt=":(" src="/static/smileys/triste.png"> ". Vous conviendrai qu'on fait plus rassurant… <a class="footnote-backref" href="#fnref-exemple" title="Retourner au texte de la note 2">↩</a></p>
</li>
</ol>
</div>Préparation du déploiement de la v1.3, message #331212014-12-08T11:46:34+01:00Eskimon/@Eskimonhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33121<p>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.</p>Préparation du déploiement de la v1.3, message #331182014-12-08T11:37:29+01:00firm1/@firm1https://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33118<p>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 ?</p>
<hr>
<p>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.</p>
<h4>Le problème de tri</h4>
<p>Il y'a deux types de tri ici (qui ont été visiblement confondus) : </p>
<ol>
<li>Le tri des messages sur un topic</li>
<li>Le tri des messages dans le forum</li>
</ol>
<p>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.</p>
<p>Dans le cas 2, le tri par pubdate est justifié car il répond parfaitement au besoin (uniquement d'affichage).</p>
<p>Ce "bug" n'existe donc pas selon moi.</p>
<h4>Le problème de renommage des tutoriels</h4>
<p>Comme je l'ai dis <a href="http://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32602">ici</a>, je l'ai testé et il est fonctionnel.</p>
<p>Le post d'Eskimon <a href="http://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32600">juste avant</a> 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.</p>
<p>Voilà, ce que j'ai comme info. Y'a encore des trucs pas clairs ? Y'a t-il une vrai raison <strong>technique</strong> pour laquelle la 1.3 n'est toujours pas en production ?</p>
<hr>
<figure><blockquote>
<p>On bloque tout merge dès qu'on a atteint une taille critique ?
</p>
</blockquote>
<figcaption><p>SpaceFox</p></figcaption></figure><p>J'espère qu'on arrivera jamais là.</p>Préparation du déploiement de la v1.3, message #331152014-12-08T11:07:44+01:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33115<p>Si j'ai bien compris ce que firm1 m'a expliqué en privé, en fait c'est pas ça.</p>
<p>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 ?</p>
<p>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 ?</p>Préparation du déploiement de la v1.3, message #331142014-12-08T10:55:18+01:00artragis/@artragishttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=5#p33114<p>En fait je pensais avoir compris :</p>
<ul>
<li>c'est pas bien de faire avec les dates</li>
<li>on a essayé autrement mais on a pas réussi</li>
<li>du coup on a préféré dire "bon bah on revient comme avant, ça marche mieux".</li>
</ul>
<p>C'était ce que j'avais compris. Mais Spacefox, tu m'as mis un gros doute.</p>
<p>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 !</p>Préparation du déploiement de la v1.3, message #329342014-12-06T13:34:20+01:00firm1/@firm1https://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32934<blockquote>
<p>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.</p>
</blockquote>
<p>Bon bah perso j'abandonne. <img alt=":(" src="/static/smileys/triste.png"></p>
<p>Si un dev se sent de faire l'explication …</p>Préparation du déploiement de la v1.3, message #329312014-12-06T13:10:53+01:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32931<blockquote>
<p>Je l'ai pourtant répété nombre de fois sur l'<a href="https://github.com/zestedesavoir/zds-site/issues/1823#issuecomment-65658898">issue en question</a>. le "bug bloquant" n'existe pas. Pour la simple et bonne raison qu'il a été <a href="https://github.com/zestedesavoir/zds-site/pull/1828">corrigé/hotfixé par gustavi</a> 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é.</p>
</blockquote>
<p>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.</p>
<p>J'ai <a href="https://github.com/zestedesavoir/zds-site/issues/1862">créé une issue spécifique pour ce sujet</a> avec tous les détails.</p>
<blockquote>
<p>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. </p>
</blockquote>
<p>Sauf que comme on l'a déjà vu, attendre trop longtemps c'est se retrouver avec une release géante, ce qui est <em>aussi</em> l'assurance de se planter et on en a <em>déjà</em> fait l'expérience.</p>
<p>J'en déduis donc que la seule solution, quand on commence à avoir beaucoup de contenu dans une release, c'est <strong>de bloquer tout merge jusqu'à ce que quelqu'un soit disponible pour faire une release</strong>.</p>
<p>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 <em>s'inquiéter du sort de la release</em>. C'est pas des outils qui vont nous aider à ça.</p>
<p>PS :</p>
<blockquote>
<p>Là on s'est retrouvé avec 0 DTC pendant deux semaines</p>
</blockquote>
<p>Non. On s'est retrouvé sans DTC <em>pendant un mois</em>.</p>Préparation du déploiement de la v1.3, message #329282014-12-06T12:12:48+01:00firm1/@firm1https://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32928<figure><blockquote>
<h4>Pourquoi a-t-on abandonné cette release ?</h4>
<p>…
2. On a toujours un bug bloquant après 2 semaines de tests</p>
</blockquote>
<figcaption><p>SpaceFox</p></figcaption></figure><p>Je l'ai pourtant répété nombre de fois sur l'<a href="https://github.com/zestedesavoir/zds-site/issues/1823#issuecomment-65658898">issue en question</a>. le "bug bloquant" n'existe pas. Pour la simple et bonne raison qu'il a été <a href="https://github.com/zestedesavoir/zds-site/pull/1828">corrigé/hotfixé par gustavi</a> 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 : </p>
<figure><blockquote>
<p>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.
</p>
</blockquote>
<figcaption><p>SpaceFox</p></figcaption></figure><p>Je l'appuierai en disant, qu'il faut <strong>impérativement</strong> 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.</p>
<p>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.</p>
<p>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. <strong>ç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)</strong>, vaut mieux attendre que de se lancer avec l'assurance de se vautrer par la suite. Les ressources pour une releases sont : </p>
<ul>
<li>les testeurs (il y'en a eu pas mal en préprod, et ça c'était cool)</li>
<li>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.</li>
<li>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)</li>
<li>un DTC : qui suit particulièrement l'état des tickets de release.</li>
</ul>
<p>Notons que (oui je reviens à a charge) : bon nombre des problèmes exposés ici, si on avait un outil <strong>comme</strong> JIRA, ça aurait résolu pas mal de soucis (une vue "état de la release", attribution de tache "MEPP" à quelqu'un, etc.)</p>
<p>Voilà un peu ce que je pensais de tout ça.</p>Préparation du déploiement de la v1.3, message #329092014-12-06T09:13:08+01:00gustavi/@gustavihttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32909<p>Je suis également pour que toutes les QA des PR soient reprises et testées sur la preprod. Ça permettra une double sécurité.</p>Préparation du déploiement de la v1.3, message #328972014-12-06T00:23:03+01:00SpaceFox/@SpaceFoxhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32897<h3>Abandon de la mise en production de la v1.3</h3>
<h4>Statut</h4>
<p>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 <code>dev</code> 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 <code>dev</code>.</p>
<p><strong>La version v1.3 est donc officiellement abandonnée.</strong></p>
<h4>Et maintenant ?</h4>
<ol>
<li>Merger les correctifs de release dans <code>dev</code></li>
<li>Fermer cette release</li>
<li>Relancer une procédure de release sur une <em>nouvelle</em> v1.3 (sans doute appelée v1.4, je n'ai encore rien décidé à ce sujet), à partir d'une version actuelle de <code>dev</code>.</li>
</ol>
<h3>Analyse post-mortem</h3>
<h4>Pourquoi a-t-on abandonné cette release ?</h4>
<p>Deux facteurs principaux :</p>
<ol>
<li>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</li>
<li>On a toujours un bug bloquant après 2 semaines de tests</li>
</ol>
<p>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.</p>
<h5>Concernant le manque de suivi</h5>
<p>Le fait que je lève le pied en novembre était prévu de longue date, et normalement connu.</p>
<p>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) :</p>
<ol>
<li>La release devenait très grosse, il était temps de lancer quelque chose</li>
<li>Le rythme très élevé de développement me laissait penser qu'on aurait de quoi faire le suivi</li>
</ol>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<h5>Concernant le bug bloquant</h5>
<p>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.</p>
<p>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.</p>
<p>D'ailleurs, j'en profite pour rappeler ici une règle simple :</p>
<p><strong>Il est absolument <em>interdit</em> de merger son propre code</strong>. Même s'il vous paraît inoffensif.</p>
<p>Les deux seules exceptions tolérées sont :</p>
<ol>
<li>Le cas d'un hotfix de production</li>
<li>Un code qui ne touche <em>que</em> de la documentation ou des commentaires. Et encore, là vous devez laisser le temps aux autres développeurs de le commenter au besoin.</li>
</ol>
<h4>Que faire pour éviter un nouvel échec</h4>
<p>Voici ce que je propose :</p>
<ol>
<li>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.</li>
<li>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 !</li>
<li>Toute autre bonne idée est la bienvenue…</li>
</ol>Préparation du déploiement de la v1.3, message #326882014-12-04T22:17:50+01:00Eskimon/@Eskimonhttps://zestedesavoir.com/forums/sujet/1713/preparation-du-deploiement-de-la-v13/?page=4#p32688<p>Yep je confirme l'heure de décalage <img alt="^^" src="/static/smileys/hihi.png"></p>