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.