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

firm1, lundi 16 juin 2014 à 14h35

J'ai une question sur la fermeture des tickets.

Un ticket peut/doit etre ferme apres la phase de QA + merge ou apres un dernier test en prod' ?

Eskimon

Si j'en crois ceci :

En cours / Validation : État du ticket une fois qu'il a été pris en charge. Une fois le dev terminé, il passe de "en cours" à "validation" pour être testé. À l'issue du test, soit il repasse "en cours", soit il est fermé.

nohar

On peut fermer directement quand c'est mergé.

16/06/14 à 14h35

Tuto: Réussir un entretien | Articles : le Big Data / Elasticsearch / Continuous Delivery | Projet : Zest Writer

+2 -0

nohar, lundi 16 juin 2014 à 18h09

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.

16/06/14 à 18h09

I was a llama before it was cool

+0 -0

speedking, lundi 16 juin 2014 à 19h53

test en prod

Ca ma fait grincer les dents !

16/06/14 à 19h53

+1 -0

Eskimon, lundi 16 juin 2014 à 19h55

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

16/06/14 à 19h55

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

+0 -0

Alex-D, lundi 16 juin 2014 à 21h59

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.

16/06/14 à 21h59

Mon site perso //// Mes compos //// Ma nouvelle chanson

+0 -0

nohar, lundi 16 juin 2014 à 23h33

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 !

16/06/14 à 23h33

I was a llama before it was cool

+0 -0

firm1, mercredi 18 juin 2014 à 20h43

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.

18/06/14 à 20h43

Tuto: Réussir un entretien | Articles : le Big Data / Elasticsearch / Continuous Delivery | Projet : Zest Writer

+5 -0

Alex-D, mercredi 18 juin 2014 à 21h05

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.

18/06/14 à 21h05

Mon site perso //// Mes compos //// Ma nouvelle chanson

+0 -0

nohar, mercredi 18 juin 2014 à 21h09
Modifié

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.

18/06/14 à 21h09
Modifié

I was a llama before it was cool

+0 -0

Alex-D, mercredi 18 juin 2014 à 21h27

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

18/06/14 à 21h27

Mon site perso //// Mes compos //// Ma nouvelle chanson

+0 -0

Eskimon, jeudi 10 juillet 2014 à 20h58

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

10/07/14 à 20h58

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

+2 -0

nohar, jeudi 10 juillet 2014 à 22h17

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

Merci Eskimon.

10/07/14 à 22h17

I was a llama before it was cool

+0 -0

Eskimon, jeudi 10 juillet 2014 à 22h20

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.

10/07/14 à 22h20

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

+0 -0

Eskimon, vendredi 11 juillet 2014 à 20h51

Bon… Cet aprem' j'ai tenté un truc. J'ai "formé" deux jeunes gens à la QA en leur montrant pas a pas la procédure a suivre pour faire les choses…

Ca m'a permis de découvrir une chose : Les "Notes pour la QA" sont indispensables…

Reprenons mon cas d'exemple.

J'ai montré sur la PR "Gravatar". Cette dernière corrigeait un souci simple, l'email utilisé pour appeler gravatar doit etre en minuscule, sinon le hash est mauvais. C'est tout con et vraiment simple à QA. Seulement une personne ne connaissant pas Gravatar ne peut pas faire la QA. Et pour cause, pour ce "bug", si on le test sans modif pour le constater, on voit juste que le gravatar est différent selon l'email (avec ou sans majuscules). En soit on constate visuellement pas de réelle problème.

Je pense donc qu'il faut aller au dela de ce qui nous parait évident en tant qu'habitué et parce qu'on sait d'avance quoi attendre. Il faut reussir a se mettre a la place de la personne pour vulgariser a minima dans les cas moins classique meme s'ils sont triviaux. Je sais que c'est un exercice chiant (rédiger une PR) mais c'est la garanti d'une prise d'initiative de la part des validateurs de PR.

Si qqun voit le truc, fait un test et voit pas de bug évident il va juste se dire "comprend pas ca bug pas". S'il est pro actif il posera une question sur GH, sinon il passera son chemin…

Dans mon "mini-training" j'ai essayé d'insister sur "Poser des questions !!" mais je sais que tout le monde n'est pas à l'aise avec ca…

Bref, il faut vraiment se mettre à la place des validateurs, sans pour autant etre trop cadré pour ne pas rater des cas… C'est difficile !

11/07/14 à 20h51

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

+6 -0

Eskimon, mercredi 24 septembre 2014 à 10h35

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 ?