Annexes.

Est-ce que tu vérifies les métriques business lors de tes canary releases ?

Ludovic (Netflix) : En général oui, chaque équipe peut définir les métriques à comparer qui correspondent le mieux à leur service (donc les business métriques de leur service), à côté des métriques "standard" (% cpu, erreurs IPC, latences IPC, etc...)

Est-ce que les canary releases mesurent uniquement les erreurs ou également les problèmes de performances ?

Ludovic (Netflix) : Comme décrit dans la question précédente, différentes métriques peuvent être comparées en fonction des équipes. Il est donc possible de comparer la performance (par ex. % cpu ou latences IPC). Cependant, le but d'un canary n'est pas vraiment de détecter les régressions de performance mais d'indiquer qu'une nouvelle version peut être déployée sans (ou peu de) danger. Idéalement les régressions de performance sont faites séparément par squeeze / load testing (quelle est la performance du service sous charge, jusqu'où peut il être poussé avant de basculer, ...).

Les canary releases sont-ils injectés sur une plateforme de production distincte ?

Ludovic (Netflix) : Les canary releases sont un groupe de serveurs distincts mais ils reçoivent un (faible) pourcentage du trafic de production (donc du groupe de serveurs principal / de production)

Les échantillons canary sont générés aléatoirement ?

Ludovic (Netflix) : Oui, de façon à ne pas impacter les clients. Un client faisant une requête peut aléatoirement aller sur un canary ou la version de production ("contrôle"). Si un canary provoque une erreur, une nouvelle tentative (retry) a de fortes chances d'être traitée par une instance de contrôle et donc n'impactera quasiment pas le client (cela nécessite cependant d'avoir implémenté une stratégie de nouvelle tentative). Il est cependant aussi possible de faire un "sticky canary", c.à.d. qu'à la base les échantillons sont aléatoires mais un client ayant une requête traitée par un canary restera sur le canary (pareillement pour le contrôle). Cela permet de détecter plus rapidement un problème dans le canary qui ne sera pas masqué par une nouvelle tentative traitée par le contrôle. Par contre ce type d’expérimentation est plus délicat et réactif pour arrêter le canary rapidement (et automatiquement) si beaucoup d'erreurs sont détectées pour ne pas impacter les clients d'un mauvais canary trop longtemps.

Quels outils utilisez-vous dans la stratégie QA (outils techniques, outils organisationnels, etc....)

Chaque guilde (Android, iOS, back, front etc.) a choisi les technologies pour implémenter les tests d'intégration. Le facteur le plus important étant la facilité d’usage pour que les développeur.ses l'adoptent facilement. On a donc choisi des technos implémentées dans les outils de développement et qui peuvent s'intégrer dans notre outils de CI/CD :

Outils organisationnels :
On se base sur des principes agiles (Grooming en 3 amigos, écriture des UAT en gherkin) dans les FT pour mieux anticiper la qualité en phase de conception et surtout partager les connaissances des différents membres de l’équipe.
On essaye également d’appliquer le fail fast pour les tests automatiques, donc cela implique d’avoir une pyramide de tests qui soit cohérente (plus de tests unitaires, moins de tests E2E) et exécutés tôt et souvent.
En somme, nous appliquons la notion de “Shift Left”.

La stratégie est en évolution / déploiement progressif, on itère pour optimiser au fil de l’eau, il y’a un stand-up public tous les 15 jours pour communiquer l’avancement, les pains points, les blocages. Nous utilisons Confluence pour documenter toutes les étapes de la stratégie, les guidelines Qualité, les outils utilisés.

Est ce que votre stratégie QA est différente entre la team App mobile et le team Web ?

Nos Features Teams sont pluri-disciplinaires, donc nous n’avons pas de team spécialisée Web ou Apps. Les principes appliqués sont les mêmes (fail fast, grooming en 3 amigos), la volonté d’avoir des tests automatiques à chaque niveau est la même. Les outils utilisés sont différents en fonction des contraintes liées au support.

N'est-il pas possible de tester une sorte de swarming team (dont le rôle est, peut être, a définir) ?

Hervé (leboncoin) : A priori je répondrais non à cette question. La raison de ma réponse est liée à la raison d'être même du swarming. En effet, le swarming a pour objectif d'aider à réallier des fonctionnalités impactant plusieurs équipes, en créant une équipe temporaire avec plusieurs représentants de ces équipes.

Je m'aperçois qu'il me faut être plus précis : c'est en fait une équipe (Feature Teal) "lead" sur le projet qui accueille des représentants et non une équipe “from scratch”. C'est un élé ma ment essentiel du swarming sinon, on parle juste de Taskforce.

La taskforce est une composition "best of" de personnes de chaque équipe nécessaire à solutionner le problème (alimentant au passage le culte des sauveurs). L'effet indésirable de ce pattern tient dans le fait qu'à la fin de l'exercice, le dispositif se disloque et pose la question de la propriété et, in-extenso, de la responsabilité du code réalisé. Et cela devient souvent "le problème de personne"...

Dans le cas d'un swarming, c'est différent. Le contrat est clair dès le début: une équipe meneuse accueille des personnes d'autres équipes pour former un essaim temporaire autour de sa codebase. Chaque collaborateur est un émissaire qui a autorité et code majoritairement sur la codebase de son équipe. En revanche, l'essaim apportera une proximité et un focus. Il créera une relation de confiance entre des collaborateurs qui n'ont pas l'habitude de travailler quotidiennement ensemble. Les personnes accueillies pourront faire des code reviews croisées plus efficaces, car plus connectées au problème fonctionnel que l'on adresse. Les questions architecturales seront suivies et adressées par l'équipe meneuse même si l'intégralité des collaborateurs de celle-ci ne travaillent pas sur le sujet de l'essaim.

Ainsi, pérenniser un swarm sous forme de "swarming team" relèverait presque du contre-sens puisque la valeur des essaims tient dans la capacité de l'organisation à en créer, les disloquer , puis en recréer de nouveaux régulièrement.

Comment se passe l'accompagnement managérial lors d'un swarming ? La personne garde le même manager ?

Les collaborateurs qui rejoignent l'équipe meneuse pour la construction de l'essaim restent attachés à leur équipe d'origine. Ainsi ils gardent leur manager.

Pour les essaims qui durent plusieurs mois (~1 trimestre ou plus), nous avons vu les managers de l'équipe meneuse proposer des one-on-one réguliers aux collaborateurs "invités" pour leur proposer le meilleur accompagnement possible. Cela s'est révélé être une bonne pratique.

Comment motiver les personnes à oser se former ? À oser admettre qu'ils ne savent pas ?

Chloé: Pour oser se former, il faut déjà oser admettre de ne pas savoir, de ne pas être “expert” sur tout. C’est quelque chose qui peut encore être mal vu dans certaines entreprises/organisations. Un élément donc principal est de construire une culture où il est OK de ne pas savoir et où on a la possibilité de le communiquer. L’onboarding de nouveaux talents peut être un bon moment pour le faire “je n’attends pas de toi de tout savoir, et je m’attends à ce que tu continues à apprendre chez nous - d’ailleurs je considère que c’est notre rôle en tant qu’entreprise de te donner un cadre pour te former”. Déjà dire ça, c’est faire selon moi la moitié du chemin. On casse ce syndrome de l’imposteur silencieux et culpabilisant qu’on a au fond de soi. Je pense qu’aussi il est important de questionner sa culture Tech et la façon qu’on a d’évaluer une “excellence technique”. Montrer qu’on n’évalue pas un·e bon·ne dev sur sa seule capacité à produire des lignes de code mais aussi sur sa méthodologie, son recul … bref sa capacité à grandir, s’interroger, partager et se former.

Charline: Lead by example. Un manager qui assume dire “je ne sais pas”, qui plébiscite et partage ses derniers apprentissages et découvertes auprès de son équipe, qui leur propose de se mettre des créneaux dédiés à la veille et à la formation. Finalement, même dans la vie privée, on veut toujours avoir réponse à tout, soit par question d’ego, soit par peur d’être vulnérable (ou les deux ;) ), mais notre génération est capable d’assumer et de célébrer sa vulnérabilité. Même dans l’apprentissage. Mettons en avant les “learn it all” plutôt que les “know it all”. Deuxième point, il n’est peut être pas toujours aisé d’être seul-e dans sa démarche d’apprentissage, mettre à dispo des systèmes de buddy learning peut être moins intimidant (ou dégradant) pour ceux-lles qui n’osent pas aborder de nouvelles connaissances.

Alexandre: Par la culture de l'entreprise, je pense. Dans une société où les leaders n'ont pas peur d'affirmer ne pas savoir, et de valoriser l'apprentissage, les gens auront beaucoup moins de mal à assumer qu'on apprend toute sa vie. C'est OK d'apprendre, et c'est même une étape fondamentale de notre construction.

Guillaume: Dans mon cas, je privilégie en ce moment (contexte COVID) des moments d’apprentissage collectifs, ou bien je m’assure que la démarche individuelle d’apprentissage ne se fasse pas de manière isolée du groupe. J’ai l’impression qu’il n’était pas nécessaire (ça aurait probablement été contre-productif) de défendre une vision socratique rigoriste - et un peu culpabilisante à mon sens - de la pensée (“je sais que je ne sais rien”) pour mes collaborateurs, lorsqu’il s’agit de leur proposer des opportunités d’apprentissages (conférences, Q&A aves des pairs, discussion avec d’autres entreprises). Ce que j’observe, c’est que les formats événementiels qui ont le mieux marché réunissaient 3 conditions:

  • une dynamique collective des guildes de passer ensemble un moment de veille sur les bonnes pratiques
  • un temps “protégé” en journée par leur management (hors temps de pause, type déjeuner ou début de soirée)
  • un cadre de confiance : des intentions réciproques “validées” par les interlocuteurs (nos tech, et la communauté ou l'expert partenaire), avec un ordre du jour clair.