Gestion des tickets sur GitHub et organisation générale

Exact. La QA déclenche le merge, le merge déclenche la fermeture de l'issue. Pas besoin de "test en prod" (fondamentalement le test est censé être fait avant la prod, et en prod il est trop tard pour tester).

Si une issue est QA-isée, validée, fermée, et qu'elle déclenche quand même une erreur en prod (parce que l'erreur est humaine et que la QA peut avoir zappé un cas particulier), alors l'issue est réouverte.

test en prod

Ca ma fait grincer les dents !

Ca roule, je voulais en avoir le coeur net

Ca ma fait grincer les dents !

Ouai c'est vrai c'est con en fait XD

L'idéal serait de remettre sur pied une preprod pour la beta publique, histoire qu'on puisse tester à plusieurs sans tout casser et sans avoir des soucis (genre Solr) liés à la config locale.

Yep.

Ça me fait penser que je proposerais bien un système de branches pour coller avec ce process, j'ai une idée dont on pourrait discuter. Mais ça attendra après la V1. Je voudrais pas tout chambouler en une semaine non plus !

Hello,

Je sais bien qu'on est en rush beta et tout, mais je tiens tout de même à parler de nos démarches de bug fix. Le projet a un bug plutôt délicat concernant les fichiers de tutos, ce qui a entrainé certaines situations de conflits un peu partout avec une myriade de d'issue toutes liées au même problème source. Ce qui m'a fait tilté c'est principalement le fait que certaines PRs ont tentée de résoudre les PRs de manière individuelles, ce qui avait pour conséquence immédiate de créer une ambiguité dans les fichiers des tutos.

Autant le front-end est un truc qu'on peut réparer facilement, autant certaines parties du back (tout ce qui touche la bd) aussi on peut réparer facilement, autant, tout ce qui concerne les fichiers physiques stockés, il faut faire très très attentions.

Je proprose donc, de revoir un peu le processus de QA. Actuellement les PR sont testées par les QA de manière fonctionnelle (ont vérifie que le bug en question est fixé et qu'il y'a pas d'impact négatif). Cependant, les PR qui touchent à des fichiers sont très délicates, parce que c'est le genre de chose qu'on ne peut pas rattraper plus tard. Et on ne va pas lancer une V1 et dire 6 mois plus tard, "Coucou les mecs, on a repensé notre structure de stockage et du coup, l'historique de vos tuto est irrécupérable".

En résumé, je penses qu'il faudrait obligatoirement une review technique coté back pour chaque PR qui touche au stockage (fichiers tutos, articles, images). Je pense même qu'il faudrait le rajouter dans le contributing.md pour que les contributeurs signale une PR qui touche aux fichiers sensibles.

J'ai envie de dire : pareil pour le front. Les gens testent juste chez eux, alors qu'en réalité absolument il faut tester sur plein de supports.

Au final, je considère que c'est lié à la "code review" que je proposais tantôt.

Je suis d'accord avec firm1.

Puisque je vais bientôt merger les post-its de ce forum, je vais en profiter pour essayer de rendre cette info bien visible pour que les contributeurs en tiennent compte lorsqu'ils interviennent sur une issue (que ce soit du point de vue dev ou QA).

Pour ce qui est du front, c'est différent. Il suffit de préciser dans le process qu'un test de QA front doit être fait sur un panel représentatif de browsers : une erreur qui passe au travers est de toute façon beaucoup moins critique que le cassage irréversible de la rétro-compatibilité sur la structure des tutos, puisque c'est réparable a posteriori, donc ça ne justifie pas une code review systématique.

Ok, j'ai pigé l'argument j'avais pas saisi le "irreversible".

Je me suis permis de rajouter les labels "Facile" sur les PR qui sont vraiment noob friendly a QAtiser.

Excellente initiative. Ça va nous être utile très bientôt.

Merci Eskimon.

Le seul truc un peu con c'est que ca apparait pas dans la page PR (mais ca apparait dans la page issues). Donc faut les ouvrir une à une pour vérifier si c'est simple ou pas…

Du coup je pense qu'il faudrait remettre en avant le "Notes pour QA" comme certains avait commencé. Quelqu'un qui ne connectait pas trop l'architecture peut facilement passer à côté de chose. Par contre il faut volontairement balayer large pour être sur de sur-couvrir la PR en termes de use case.

Salut tout le monde !

Il me semble que des membres étaient intéressé pour venir filer un coup de main a tester sur la preprod. Le cas échéant est-ce que tout les devs sont ok pour qu'on s'organise et leurs donnent l’accès ?

Yep je pense même que pour l'arrivée de la V 1.1 sur la préprod, il faudrait faire un sujet dédié pour demander des test approfondies.

C'est prévu

Il va falloir supprimer ce topic ou le déplacer (cf https://github.com/zestedesavoir/zds-site/issues/1713).

Ce topic est un peu outdated !

Il faudrait soit l'actualiser, soit ajouter un message pour dire qu'il n'est plus d'actualité et le dés-épingler.

Surtout qu'on a de la doc qui est plus a jour sur read the docs et qui fait donc doublon.

UP ! Ce sujet date vraiment, n'est plus à jour mais reste épinglé ! Donc si un Staff peu au moins le dépingler ce serait sympa ?