Feature branch testing (& reporting)

[Jérémie Bresson]

Bonjour à tous,

Dans notre équipe on se pose la question de faire plus de tests directement sur les feature-branches.

Je ne parle pas de tests automatisés (type teste unitaires ou d'intégration avec JUnit) mais de test manuels faire par notre équipe QA et aussi de retour potentiel fait par les features owner / product owner.

Nous voulons passer d'un modèle où une PR est mergée quand les tests automatisés et la code review sont bons, à un modèle où plus de choses seraient validées avant de merger.

La partie déploiement à partir d'une feature branch est presque résolue, mais on vient de se rendre compte qu'on allait avoir également une nouvelle organisation à trouver.

Deux théories s'affrontent:

I. faire des retours dans la PR ouverte.

II. faire des retours dans l'issue tracker.

Je ne vais pas donner de nom de produits, parce qu'il me semble qu'il n'y a finalement pas vraiment de grosses différences de modélisation entre les outils.

Si je me trompe je suis preneur de conseils.

Si on fait la stratégie I:

Comment traquer l'état d'une PR (ouverte aux revues de code, ouverte pour les retours de QA ou de l'équipe produit, en cours de correction)

Souvent l'état d'une PR c'est assez limité.

La discussion par conversation est aussi assez limitée.

Comment identifier ce qui a été corrigé entre un commit et le suivant au niveau de la PR.

On se dit qu'il va falloir pas mal de règles pour éviter que les conversations partent dans tous les sens et traquer ce qu'il reste à faire.

Une PR permet souvent à chaque reviewer d'approver.

Mais s'il y a encore des changements, soit on demande à chacun d'approver à nouveau, soit on ne sait pas quel état a été approver quand.

Si on fait la stratégie II:

En fait notre issue tracker n'est pas vraiment fait pour s'adapter aux mondes des feature branch en parallèle.

Jusqu'à maintenant on avait des versions claires et pour chaque issue on peut dire avec quelle version cela ne marche pas et avec quelle version la correction est livrée.

Mais dans un monde où on teste sur des versions partielles tout devient plus compliqué.

Il faudrait presque torde l'outil avec des tags ou des sous-projets pour pouvoir l'utiliser correctement.

On redoute le côté usine à Gaz.

---

Vos retours sont les bienvenus.

Si vous pensez qu'il existe d'autres communautés (francophones ou anglophones qui peuvent nous donner un point de vue), je veux bien des liens.

On se disait aussi qu'on allait regarder du coté de grands projets open source… Mais cette partie n'est pas toujours vraiment documentée.

Nous sommes un éditeur de logiciels plutôt classique (on fait du on-prem donc on a plusieurs versions majeures en prod)

Actuellement 22 dans l'équipe de dev (en comptant tout le monde: CTO, Devs, QA, tech-writer) avec un potentiel de croissance (c'est aussi pour cela qu'on cherche à se réorganiser…).

Bref on ne doit pas être les seuls dans ce cas et on en revient pas de se dire que les outils classiques qu'on utilise n'ont pas l'air de répondre à notre besoin.

Merci d'avance pour vos lumières.

[Alain Helaili]

Hello Jérémie, 

Il manque quelques éléments pour pouvoir se prononcer, et il est super important de partir sur une solution qui soit compatible avec votre mode de travail complet. L’usine à gaz arrive dès lors que tu adoptes un workflow qui ne prend pas en compte ta manière de gérer le projet ni ta manière de déployer ou de livrer. Une grande partie de ceux qui ont adopté GitFlow se reconnaitront. 

Autres points importants: 

- la durée de vie et la taille de tes PRs: beaucoup de tes questions perdent de leur importance dès lors que tu t’astreins à développer dans des PRs très ciblées avec une durée de vie restreinte (3 jours max par exemple),

- les options que tu as mis en place pour expérimenter en prod (feature flags) sont également structurantes, 

- certains outils te permettent de lier le cycle de vie de tes PRs à tes Issues. Ca peut aussi permettre d’aider le suivi du travail.

Plus de questions que de réponses, mais je suis dispo pour en discuter. 

Alain Hélaïli +33 6 8968 4660 hel...@github.com | @AlainHelaili GitHub.com | GitHub Enterprise

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/14d776bd-d54d-4e01-9ed6-bf14175045d6n%40googlegroups.com.

[Jérémie Bresson]

Merci pour ta réponse.

> Il manque quelques éléments pour pouvoir se prononcer,

Ok comme quoi?
On livre tous les 15 jours (pour de vrai)
On a plusieurs version majeure actives (en cours de développement ou en maintenance -- les plus ancienne n'ont pas de changements tous les 15 jours)

Notre problème n'est ni un problème de PR, de Git-flow ou de merge.

Ca marche plutôt bien de ce côté là.

Pour le moment une feature branche est mergé par une PR incluant:
Revue de code par les dev et tests automatisés OK (mais les tests type Selenium ne sont pas inclus dans cette catégorie).

La partie de test par notre équipe QA arrive qu'à la fin de notre cycle de 15 jours. L'équipe teste alors tous les changements de la 15zaine.
Si des regressions majeures sont trouvées, elles doivent être corrigées pour pouvoir publiée la version correspondant au cycle.

On veut faire plus de tests avant de merger, c'est pour cela qu'on envisage d'avoir plus de retour dans la PR…

> la durée de vie et la taille de tes PRs ... tu t’astreins à développer dans des PRs très ciblées avec une durée de vie restreinte (3 jours max par exemple)

Tout dépend ce que tu fais dans une feature branch.
L'idée d'essayer d'y aller par petits changements est intéressante, mais ne me semble pas forcement réaliste notamment dans le cas de nouvelles fonctionnalités.

> les options que tu as mis en place pour expérimenter en prod (feature flags) sont également structurantes, 

Notre produit est hyper configurable… Mais je ne vois pas le rapport avec la possibilité de tester à partir d'une feature branche.

> - certains outils te permettent de lier le cycle de vie de tes PRs à tes Issues. Ca peut aussi permettre d’aider le suivi du travail.

Ok. C'est ce qui semble le nerf de la guerre (on a déjà pas mal de liens et d'automatisme), mais c'est pas évident de trouver le setup qui nous convient.

Les outils documentent tous assez bien leurs fonctionnalités, mais il y a peu de retour d'expérience de la vrai vie par type d'utilisateurs (je pense que les cas sont différents si tu développes un framework open-source ou si tu édites un logiciel complet)

[yannick grenzinger]

Bonjour,

Une question (ptet déjà répondu) me vient à l'esprit pourquoi voulez-vous intégrer les tests manuels à la "PR / feature branch"? 

Merci. 

Yannick 

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/c695c932-307a-48bc-9194-10c64ddf4632n%40googlegroups.com.

[Remi Forax]

De: "yannick grenzinger" <yannick.g...@gmail.com>
À: "lescastcodeurs" <lescast...@googlegroups.com>
Envoyé: Samedi 13 Février 2021 16:33:51
Objet: Re: [LCC] Feature branch testing (& reporting)

Bonjour,

Une question (ptet déjà répondu) me vient à l'esprit pourquoi voulez-vous intégrer les tests manuels à la "PR / feature branch"? 

parce que dès que tu as un marteau, tous tes problèmes ressemblent à des clous :)

Merci. 

Yannick 

Rémi

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAPbzkR0fbVHQu11GCMHWHh_ZaTb2wbfdP4Vu4DVuiaMr7DLqTQ%40mail.gmail.com.

[Jérémie Bresson]

> Une question (ptet déjà répondu) me vient à l'esprit pourquoi voulez-vous intégrer les tests manuels à la "PR / feature branch"? 

Je recule d'une case pour donner plus de contexte:

Notre fonctionnement actuel:

On developpe sur des feature branch.
Ce development peut être long, mais on se discipline à merger la branch d'origine régulièrement pour éviter les surprises de merge à la fin.
On a de l'intégration continue sur toutes nos branches.
Il y a ensuite une revue de code en utilisant une PR puis on merge.

Certainement que notre couverture de test n'est pas suffisante (notre produit à une petite dizaine d'année comme certaines lignes de code), car on ne détecte pas toutes les regressions par l'intégration continue.

On veut pouvoir sortir une release qui peut partir en prod tous les 15 jours (chaque client ne fait pas forcément là mise à jour, mais sur le nombre qu'on en a disons qu'on aura au moins plusieurs installations de chaque version).
Je ne suis pas un expert Agile/Scrum et on utilise pas vraiment ce vocabulaire, mais je pense qu'on a assez proche de la définition d'un Sprint (on parle plutôt de "release slot" suivant l'idée du release train, mais je vais utiliser "Sprint" les puristes me pardonnerons).
A la fin du Sprint, commencent les tests manuels de tout ce qui a été mergé durant le Sprint.

On fixe les régressions qui sont trouvées.

Lorsque qu'une feature-branch mergée n'est pas de qualité suffisante. On a pas mal de tensions.
Car c'est trop tard et le changement (nouvelle feature ou bugfix) correspondant à la feature branch mergée trop top pénalise les autres features qui sont aussi inclus dans le Sprint.

Et il y a des remarques du type: en fait rétrospectivement, on aurait du la décaler d'un Sprint (pour plein de raisons qui sont toutes bonnes: erreur d'implementation, erreur de conception plus en amont, ou effet de bord…).

Notre nouvelle idée:

On se dit qu'on veut décaler plus de chose en amont:

* Faire déjà des tests plus poussés avant de merger.

* Avoir la possibilité de faire une "Demo" au métier

* ...
En gros merger des feature branch avec une meilleure qualité.

Et c'est là qu'il nous semble que les outils vont nous lâcher.

Soit on se dit que cet état "je pense que je suis prêt à merger ma feature branch" est représenté par une PR, mais le type de retour que l'on peut faire sur une PR est vraiment limité.
Soit on se dit qu'il faut passer par l'outil d'issue tracker, mais c'est aussi très compliqué car toute la modélisation "detected in version", "fixed in version" est vraiment insuffisante.

> parce que dès que tu as un marteau, tous tes problèmes ressemblent à des clous :)

J'aime aussi l'humour, mais dans le cas concret on a le sentiment qu'on se pose des questions simples qui concernent certainement beaucoup de projets d'une certaine taille.
On est en mode "c'est pas possible de devoir réinventer cela".

En tout cas je suis preneur de tous vos retours.

[Thomas Recloux]

Hello Jérémie

On Mon, Feb 15, 2021, at 10:59, Jérémie Bresson wrote:

On se dit qu'on veut décaler plus de chose en amont:

* Faire déjà des tests plus poussés avant de merger.

* Avoir la possibilité de faire une "Demo" au métier

* ...

En gros merger des feature branch avec une meilleure qualité.

Une des pistes est en effet de faciliter au maximum la création d’environnements éphémères dédiés à la démonstration ou au test manuel.

Par exemple via un tag sur la pull request, ou une convention de nommage qui déclenche la création ou la mise à jour de cet environnement éphémère.

L'aspect qui est le plus souvent le plus difficile à traiter et l'initialisation des données pour ces environnements.

Bonne soirée, Thomas

[Nicolas Labrot]

Hello,

 

Soit on se dit qu'il faut passer par l'outil d'issue tracker, mais c'est aussi très compliqué car toute la modélisation "detected in version", "fixed in version" est vraiment insuffisante.

Qu'est ce qui est insuffisant? 

IMHO, une PR est un objet technique orienté collaboration dev.

Associé à une feature branch avez vous une issue dans l'issue tracker avec un workflow dédié incluant la QA?

Si besoin de faire plusieurs PR sur différentes versions (avez vous ce besoin?), et donc de faire de la QA dessus, une sous tâche par PR ne suffirait pas avec le workflow QA associé?

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/77591712-c4dc-473d-ace0-8490aaa7a03en%40googlegroups.com.

[yannick grenzinger]

Merci Jérémie, je pense comprendre mieux. 

J'ai l'impression que vous tirez une seule "branche" de dev (voir PR? Mais ça me semble pas la bonne utilisation) par "release slot" et après le merge démarre une série de tests de non régression manuels.

Je ne vois rien qui vous empêche de faire ces tests sur cette branche avant le merge. Cependant si les devs commencent autre chose en parallèle il va falloir tirer une nouvelle branche de cette branche..

Vous pouvez utiliser l'issue tracker pour suivre les problèmes et leur état sur la branche. 

Mais je ressens que je simplifie la question 🙂

J'ai aussi le sentiment que votre vrai problème c'est le besoin important de tests manuels et vous semblez mettre beaucoup d'énergie dans le suivie des régressions plus que d'éviter quelles se produisent. 

Yannick 

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/77591712-c4dc-473d-ace0-8490aaa7a03en%40googlegroups.com.

[Philippe Charrière]

Bonjour Jérémie,

Votre workflow de développement me semble cohérent et pas compliqué

En relisant l'ensemble des échanges, j'ai l'impression que c'est au niveau des revues qu'il y a un problème, peut-être que certaines d'entre-elles sont faites trop rapidement ou pas assez en profondeur (je vois souvent comme commentaire dans des revues LGTM -look good to me- et quand je trouve ça, c'est que le plus souvent je suis parti d'une déclaration de bug pour remonter vers une merge request ou pull request)

Dans un 1er temps vous devriez peut-être travailler sur cette partie en demandant par exemple au(x) reviewer(s) de la PR de préciser  dans la PR certains points (donc de les écrire) :

- qu'avez vous testé et comment ? + les résultats (si pas automatiquement fourni)

- quel est votre degré de confiance dans cette PR sur une échelle de  ... (je vous laisse choisir)

Si les réponses ne sont pas complètes et/ou le degré de confiance n'est pas bon, vous ne l'intégrez pas dans la release

Ensuite je rejoins l'idée de Thomas, si vous avez le moyen de "monter" des environnements éphémères à partir de votre feature branch, ça aide beaucoup (mais je ne connais pas votre contexte)

Un autre point à travailler c'est la taille de la fonctionnalité et le nombre de personnes affectées à la fonctionnalité (ce qui réduit le plus les ennuis c'est dans la mesure du possible d'avoir des petites features avec une personne par feature)

Pour conclure (mais je ne travaille pas avec vous donc je n'ai pas toutes les clefs) je dirais de commencer par les revues et d'être plus sévère dans l'acceptabilité d'un merge

Philippe

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAPbzkR1D%2BVRMQhY-5YHKpBWrKRKPfSRp-Ausai1GUettA%2BoGzA%40mail.gmail.com.

[Jérémie Bresson]

Merci beaucoup pour vos échanges.

Je réalise que j'ai peut être pris la discussion ici par le mauvais bout (en livrant un peu frustré quelques constats qu'on avait fait lors d'une réunion)

Je crois que je peux résumer ma question à:

On va passer à un fonctionnement avec des environnements éphémères correspondant à une feature branch (ce que nous ne faisions pas avant).
En gros c'est au moment où un dev aurait mergé sa PR que cette phase peut commencer (ou un tout petit peu avant).

Plus de personnes vont tester, faire des retours sur cet état.

Comment vous structurez ces retours sur les environnements éphémère?

* Est-ce directement dans la PR? Et dans ce cas comment avoir quelque chose d'un peut structuré?
Nous on a Bitbucket (parfois on réfléchit à changer):
  - on peut avoir une liste de "Task" qui on un statut Open/DONE
  - chaque reviewer peut dire "Ok" ou "Need works"
  - et il y a des commentaires groupé par conversations et attaché ou non à une ligne de code.

J'ai pas l'impression que GitLab ou GitHub offrent beaucoup plus de feature (c'est pour cela que je ne voulais pas nommer d'outil)

Je crois qu'on va essayer cette approche mais franchement la modélisation est limitée (et on risque de perdre rapidement la compréhension de savoir: "sur cette PR on en est où?" les tests manuels ils sont OK ou non, le feature owner il valide, ce truc c'était cassé avec ce commit, c'est bon maintenant ou non)

* Est-ce que c'est dans l'issue tracker?

Pour le moment notre champ "detected in version" est hyper simple.
Mais tout devient plus compliqué avec des environnements éphémères.
Comment dire: dans ce commit de la feature branch X?

Et ensuite pour réconcilier les issues ouverte avec l'état de la PR, c'est pas évident.

----

@Philippe charriere
Je pense qu'on est tout à fait aligné sur ce qu'on veut faire:

> le degré de confiance n'est pas bon, vous ne l'intégrez pas dans la release

Je ne connais pas bien GitLab (plus utilisé depuis 3 ans et mon changement d'entreprise).

Ta suggestion de reporting c'est de tout faire dans la PR sous forme de texte et de discussion?

Mettons qu'une personne de QA fasse un test manuel, elle le signale en commentaire?
Le dev dit ensuite en réponse "Ok c'est fixé"
Et ainsi de suite?

De même pour les notes et les autres éléments que tu nous conseilles. Tout sous forme de commentaires?

---

@Nicolas

> Associé à une feature branch avez vous une issue dans l'issue tracker avec un workflow dédié incluant la QA?

Très bon point.
Une feature branch (on veut faire un changement) est associée à une issue.
Et la QA vient faire un retour pour dire si pour eux l'issue est résolue ou non.
Mais ils font ce retour après le merge.

Peut être qu'une partie du problème vient de là. C'est certainement une piste à creuser.

---

@yannick:

> J'ai l'impression que vous tirez une seule "branche" de dev (voir PR? Mais ça me semble pas la bonne utilisation) par "release slot" et après le merge démarre une série de tests de non régression manuels.

Faudrait que je partage notre flow git (qui n'est pas trivial parce qu'on a plusieurs versions active en cours) mais pas non plus incomprehensible (proche de git-flow finalement).

Mais effectivement une partie de la friction vient du fait qu'on merge trop tot.

> J'ai aussi le sentiment que votre vrai problème c'est le besoin important de tests manuels et vous semblez mettre beaucoup d'énergie dans le suivie des régressions plus que d'éviter quelles se produisent. 

On travaille dessus car oui on a certainement trop de problème de regression.
Après comme on a cette phase de stabilisation, je pense que la qualité pour nos clients est plutôt excellente (en comparaison de ce que j'ai pu voir ailleurs).

Sur la quantité d'énergie, tout est question de point de vue… Et je pense que la description réductrice que j'ai partagée ici t'induit à penser cela.


---

J'espère avoir répondu à chacun.
Vraiment vos réponses m'aident beaucoup.

[Philippe Charrière]

tu peux lier une issue à une MR

je suis plus partisan d'avoir les discussions concernant les retours dans la MR, mais en fonction des catégories de personnes concernées ça peut rapidement devenir le foutoir

Du coup tu peux créer une issue spécifique pour les retours en lui créant un/des labels bien précis pour l'identifier (feature-toto milestone-24 prise-en-compte-des-retours etc ...)

Ou créer carrément un projet à part dédié à la prise en compte des retours et ce projet n'accueillera que des issues pour les QA, users, ...

il faut que le projet appartienne au même groupe ou orga que le projet de dev, comme ça ça sera plus facile de référencer les issue, mr, pr, ...

à ta dispo pour en discuter de vive voix si tu veux

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/0c98ede7-dbb8-4cde-b6fe-83346b6a12a1n%40googlegroups.com.

[Jérémie Bresson]

> je suis plus partisan d'avoir les discussions concernant les retours dans la MR, mais en fonction des catégories de personnes concernées ça peut rapidement devenir le foutoir

C'est ce qu'on va essayer… parce que cela nous semble aussi plus simple et cohérent.

Rendez-vous dans quelques mois pour voir comment ça se passe en pratique.

[Philippe Charrière]

👍 impatient de connaître la suite

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/df13909c-1fa4-40dc-a1bd-8a370fa9cd07n%40googlegroups.com.

[Pierre Colomb]

Bonjour,

Chez Braincube on va essayer la fonctionnalité Visual Review de Gitlab (https://docs.gitlab.com/ee/ci/review_apps/index.html) notre idée est à la fois que les dev puisse "voir" les choses lorsqu'ils font de la revue de code et aussi que les POs fassent la revue fonctionnel feature des features branches (Idealement j'aimerais que ce le PO qui approuve voir merge la MR de la feature branch). 

Aujourd'hui on a tout mis en place techniquement pour que ça marche (notamment des environnements éphémère) on a encore quelques sujets d'organisation a caller. On devrait s'y mettre pour de vrai d'ici 2 ou 3 semaines je pense. Je vous ferai un retour d'expérience. 

Je vous souhaite une bonne journée

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEGib83rCKQuUL1dSLLBw1OwP8rGJFBCxVwwGWtVHM4FSMSLaA%40mail.gmail.com.

--

Pierre Colomb
PhD

[ LinkedIn ] [ Twitter ] [ Lava JUG ]

[Baptiste Mathus]

Salut ! J'arrive après la bataille, mais je réponds keem, c'est un sujet qui m'est cher depuis quelques années :)

Le ven. 12 févr. 2021 à 14:24, Jérémie Bresson <jeremie...@unblu.com> a écrit :

Bonjour à tous,

Dans notre équipe on se pose la question de faire plus de tests directement sur les feature-branches.

Si je comprends bien vous avez des branches à durée de vie assez longue, genre 15 jours ou plus.

Ensuite vous mergez cette branch avec main/master à intervalle régulier (chacun de ces sprints de 15 jours ?)

Perso je commencerais par là, en dehors de cas très exceptionnel, je conseillerais d'éviter qu'une PR/branche soit ouverte plus de quelques jours. 

("reduce chunk size" est un des éléments critiques du Continuous Delivery. Discuté/rappelé notamment dans le livre Accelerate, chapitre 4, qui offre une approche statistiques/scientifiques pour recommander les pratiques qui font les "High performing teams").

Je favoriserais des PRs plus petites directement sur main/master et tout le monde teste/travaille sur cette branche.

Ensuite, quant à tester plus "manuellement", ça me semble ne pas être idéal et "scalable".

Je conseillerais de "shift left" et d'intégrer (encore?) davantage vos QA au développement, et faire remonter le process pour chaque story de "testing notes", en gros envisager ce qui pourrait merder et comment tester la story avant de la commencer (en fonction de la tâche, c'est normalement quelques minutes de boulot). 

Organiser une session de "test exploratoire" (on appelle ça "bug bash session" chez nous) à chaque sprint, ou tous les X sprints, pourquoi pas, mais ça doit être IMO réservé à des changements particulièrement risqués.

[Jérémie Bresson]

Aucun problème pour continuer cette discussion…

> Si je comprends bien vous avez des branches à durée de vie assez longue, genre 15 jours ou plus.

> Ensuite vous mergez cette branch avec main/master à intervalle régulier (chacun de ces sprints de 15 jours ?)

Notre vision:

* Un feature branch qui se termine en PR c'est pour un ticket (bug, new-feature, improvement…).

* Récemment on se faisait la réflexion qu'on doit encore bien travailler cette définition car il faut que cette unité soit mergeable et que donc on ne peut pas découper en tickets qui ne sont pas indépendant.

Si la feature branch dure longtemps:

* On merge régulièrement notre branche principale dans la feature-branch pour intégrer d'autres changements de l'équipe et pour éviter les surprises à la fin.

* On ne merge qu'une fois la feature branch dans la branche principale avec une PR (qui correspond aussi au moment où le ticket est résolu).

Sur la durée de vie:

Evidement l'objectif c'est d'avoir le découpage le plus fin possible pour avoir des petits changement qui sont régulièrement et rapidement intégré dans la branche principale, mais ce n'est pas toujours possible. Il y a parfois des gros changement qui durent plus que 3-4 jours.

Il est évident qu'on a un axe d'amélioration sur la détection automatisée de regression.

Mais je ne pense pas que cela soit lié à notre idée d'intégrer plus de monde (QA, PO, …) au moment de la PR.

Tu ne détailles pas du tout comment vous vous assurez de la qualité dans une PR.

Le fait qu'elle soit petite ne garantie en rien qu'elle n'a aucun effets de bord inattendus et si vous testez principalement sur votre branche principale (éventuellement en fin de sprint) cela veut dire que si une PR dont les impacts n'ont pas été vu au moment de la revue de code est mergée, tu dois la corriger en fin de sprint et tu es dans notre cas actuel (ce qui marche aussi).

[Jérémie Bresson]

> Aujourd'hui on a tout mis en place techniquement pour que ça marche (notamment des environnements éphémère) on a encore quelques sujets d'organisation a caller. On devrait s'y mettre pour de vrai d'ici 2 ou 3 semaines je pense. Je vous ferai un retour d'expérience. 

J'attends avec impatience, car j'ai regardé la doc de "Visual Review de Gitlab" et il me semble que les retours se font toujours de la même manière (sous forme de commentaires et de +1).

Ce qui m'interesse en particulier:

* A quel moment vous dite au PO de venir tester? (en même temps que les devs ou après)

* Comment faites vous le tri entre les retours (entre une ligne de code à changer et un commentaire disant que la fonctionnalité X ne marche pas comme prévu).

* Si lors de la "Visual Review" un bug est signalé, comment ce commentaire est traité? (est ce que le dev doit dire dans le thread que c'est corrigé avec la version du commit X, est ce que c'est au PO de s'en rendre compte par lui même)

* Comment vous traquez toutes les choses encore ouverte dans une PR ?