- Speaker #0
Bonjour et bienvenue à tous sur ce nouvel épisode de NON D'UN PIPELINE. Je suis Julien, votre hôte favori pour parler de CICD et je suis aujourd'hui avec Thomas. Salut Thomas !
- Speaker #1
Salut Julien !
- Speaker #0
Alors Thomas, comme d'habitude, je vais commencer par te demander de te présenter pour ceux qui ne te connaissent pas encore.
- Speaker #1
Ouais, très bien. Du coup, je m'appelle Thomas, enchanté. Je travaille à Doctolib depuis presque huit ans maintenant. Je suis J'ai fait pas mal de postes à Doctolib, j'ai commencé en tant que chef de projet technique autour des déploiements des hôpitaux au tout début, là où on devait lancer la PHP, notamment un des plus grands groupements hospitaliers européens. Et puis petit à petit, j'ai évolué un peu plus vers la technique encore, j'ai fait un bout de QA pendant quelques mois, mais à l'époque, c'était peut-être pas encore ça la QA à Doctolib, donc j'ai arrêté la QA à Doctolib. on m'a proposé de passer développeur à l'époque, de rejoindre carrément l'équipe technique. Donc j'ai rejoint l'équipe technique, je suis resté software engineer quelques années. Et puis après, je me suis intéressé à l'infrastructure, je suis passé SRI un peu plus. Et finalement, pour arriver il y a deux ans maintenant, Product Manager à Doctolib, toujours sur les sujets techniques, cette fois-ci, plus sur les sujets d'automatisation, plus CI. Un petit peu c'est dit, mais c'est... c'est pas encore vraiment mon scope donc c'est plutôt sujet CI, automatisation et légèrement de développeur expérience aussi.
- Speaker #0
Du coup ça fait un bail que tu es chez Doctolib, je disais tout à l'heure tu fais un peu partie des murs finalement, tu as vu un peu tout évoluer, tu as passé par QA et ensuite tu t'es retrouvé un peu à faire du CI maintenant, donc tu as fait un peu tout, tu as un background technique à la base en fait, tu parlais de chef de projet au début mais...
- Speaker #1
Oui j'en... petit background technique, j'ai fait une école en trois ans avec un cursus plutôt technique en découvrant PHP, etc., les fondamentaux du web. Et puis en fait, très vite, je me suis dirigé plutôt en agence et plutôt sur du fonctionnel au final. J'ai découvert vraiment le milieu de l'entreprise comme ça, on va dire. Et puis j'ai fait une petite césure à un moment et puis en revenant en France, j'ai retrouvé...
- Speaker #0
libre et puis ça m'a cher trouvé du coup ce poste de chef de projet mais du coup allié avec cette fois ci mon curriculum technique on va dire avec mes études et du coup bas chef de projet technique à dr lipp quoi ok trop bien voilà pour qu'on parle de dr libre parce que du coup c'est un plus gros expérience je pense que t'es pas si vieux que ça et ça fait huit ans que tu y es donc clairement si mes maths sont bonnes c'est quand même un gros sujet chez toi tu connais bien tu es là depuis longtemps tu as vu un peu de tout passer donc je me dis tu la connais un peu tout historique Pour se mettre un peu dans le bain et dans le contexte, Doctolib, c'est combien de développeurs aujourd'hui ? Combien dans les techniques ? A qui on a affaire un peu ?
- Speaker #1
A Doctolib aujourd'hui, on est à peu près, si je prends développeurs, vraiment software engineers, individuels, contributeurs, on doit être aux alentours de 400 de nos jours. Je ne sais pas les chiffres exacts et très précis, mais on doit être aux alentours de 400. Mais quand je suis rentré à Doctolib...
- Speaker #0
Vous vous organisez comment du coup ?
- Speaker #1
coup les 400 c'est j'ai mis que tu as pas 400 des temps d'une seule team c'est quoi ces fonctionnels alors c'est par feature team on a des domaines on est organisé en domaine et chaque domaine à plusieurs features team et chaque feature team et en général composé un schéma assez classique un product manager un engineering manager et avec ce binôme des individuels contributeurs voilà 4 5 en général par équipe certaines équipes ont plus d'autres un peu moins mais on ça varie aussi en fonction du besoin de l'équipe, du scope. Et puis en terme de technologie, initialement Doctolib reste un énorme monolith Rails. Depuis quelques années maintenant, on introduit de plus en plus de technologie. Initialement c'était du Ruby on Rails et une stack front avec du React. Aujourd'hui on a du Java notamment, on fait un peu de Rust aussi. on a de plus en plus de techno voilà qui rendent dans notre code blitz mais ça va être n'importe quel feature team ya pas de vraiment du futur par et battec non c'est ça va vachement être en fonction du scope fonctionnel de l'équipe que au
- Speaker #0
final la techno va être imposé mais sélectionné quoi ok et tu disais justement comme ça fait huit ans que tu y es et je me compte arriver il n'y avait pas 400 développeurs c'était probablement beaucoup moins au tout début
- Speaker #1
Ouais, au tout début, quand je suis arrivé, l'équipe technique, on devait être une vingtaine, je pense. Et encore, moi, j'étais entre deux autres, parce que j'étais chef de projet technique, donc je naviguais dans l'équipe technique, mais je n'en faisais pas vraiment partie. Puis il y avait, à l'époque, une équipe patient, une équipe docteur. Et puis une équipe dans laquelle j'étais le plus proche, c'était l'équipe Interfaçage, qui gérait justement tous les connecteurs entre les groupements hospitaliers, les progiciels médicaux et Doctolib à l'époque.
- Speaker #0
Tu as vu ça passer de 20 à 400 petit à petit. Tu parlais du département QA au début, du coup je suis un peu curieux, ça consistait en quoi ce département ? Est-ce que c'était un prémice du press-IA, il y avait déjà des trucs, ça existe toujours aujourd'hui cette partie de play ?
- Speaker #1
Alors le sujet de la QA est un gros sujet quand même à Doctolib, dans le sens où initialement, enfin plutôt au début de mon expérience à Doctolib, la QA n'existait pas trop en tant que team à part entière. La qualité a vachement été mise sur les épaules des développeurs et des product managers pendant très longtemps. Et encore aujourd'hui on a beaucoup cette fibre là, de moins en moins je reviendrai dessus. A l'époque, depuis le début, tous les développeurs écrivent des tests, que ce soit des tests unitaires, des tests end-to-end. Et le product manager fait aussi sa recette sur des environnements particuliers, on pourra en parler peut-être un peu plus. Mais voilà, en terme de QA, ça a surtout reposé sur les... les équipes sans avoir un profil QA à part entière. Et aujourd'hui, on voit au sein de Doctolib de plus en plus de profils QA arriver au sein des équipes en fonction des besoins. Je pense que c'est hyper positif d'avoir ce regard aussi externe en tant que QA pour justement améliorer la qualité et viser pour l'excellence à chaque fois pour nos utilisateurs. Donc ça va dans le bon sens.
- Speaker #0
Ok, ça continue en fait, c'est pas un truc qui a vraiment disparu finalement, quand ils leur font des tests, c'est complémentaire.
- Speaker #1
Ouais, exactement, à l'époque c'était uniquement Product Manager et Software Engineer, de nos jours c'est Software Engineer, Product Manager, QA dans certaines équipes, et aussi l'écriture de tests continue toujours et a toujours continué, on a une énorme stack de tests automatisés à Doctolib. aujourd'hui on doit avoir alors j'ai pas les chiffres très exact mais ça doit être autour de 90 mille tests qui tourne qui tourne plusieurs fois plusieurs fois un bon nombre de fois même par jour à doctolib et pour ça on a toute une infra etc qui va derrière mais on pourra en parler justement justement
- Speaker #0
c'est intéressant si vous avez des tests alors si vous avez commencé à l'entrée des tests c'est normal que vous venez 90 milles du coup parce que bon je pense que la stack a beaucoup grossi niveau soft en dix ans d'automobile a dit disons clairement donc je pense que c'est un peu c'est un peu grossi quoi mais du coup ça ressemble à quoi votre stack de tests j'imagine qu'il ya beaucoup de trucs du coup mais on grosse maille tu peux expliquer un peu comment ça se passe vous partie ci a été c'est ouais
- Speaker #1
alors le vaste sujet alors on a initialement pas mal de tests n 2 n à doctor lib pendant pendant pas mal de temps on mettait beaucoup l'accent sur les tests n 2 n pour valider au final que nos end users étaient vraiment satisfaits et que le comportement était correct in fine pour nos utilisateurs. Maintenant, depuis plusieurs années, on a refondu intégralement notre testing stratégie pour viser à avoir une testing pyramide qui est beaucoup plus régulière, on va dire. On investit beaucoup plus sur des tests unitaires, des tests de contrat, etc. pour justement réduire petit à petit cette footprint que nos tests end-to-end ont, qui sont forcément très utiles et qu'on continue encore d'écrire, mais qui ne permettent pas forcément de tout valider simplement, qui sont aussi très coûteux, aussi bien en termes de duration, de feedback loop, que d'infrastructures nécessaires derrière, et donc forcément de coûts de dollars littéralement.
- Speaker #0
Clairement, quand tu fais des CLS de cette taille-là, là tu vois le coût... non seulement en temps et en argent à la fin, parce que ça coûte cher l'infrastructure pour tourner tout ça et ça coûte des fois moins cher quand même que les développeurs, donc il faut positiver, on s'est vu avoir des tests que le développeur qui te charbonne à essayer de corriger les problèmes que tu as fait avec les tests, mais c'est vrai que c'est un sujet souvent pour beaucoup d'équipes.
- Speaker #1
Ouais très clairement, peut-être te faire l'historique un peu de là où on est parti, enfin de ce que j'ai vu au début de mes huit ans en Doctolib. Au tout début nous on était sur une stack Jenkins tout à fait classique que j'ai à peine connu au final parce qu'elle s'est fait vite remplacer et donc sur sur notre Jenkins avec nos runners au final on avait toute la partie CI et la partie test execution Ce qui était agréable dans le sens où tout était configurable de notre côté Mais c'était en même temps pas facile à maintenir de notre côté vu la taille de l'équipe à l'époque Et puis il n'y avait pas vraiment de profil dédié aux plateformes, à la CI etc Donc c'était un peu difficile de suivre pour tout le monde Et donc après ça au final on a très vite commencé à migrer au fur et à mesure que les... notre stack de tests a commencé à grossir, on a fait une première migration vers un outil qui s'appelle Heroku CI, c'est la partie CI de Heroku. Je ne sais pas si c'est encore très connu de nos jours, je ne me rends pas compte depuis le rachat de Heroku, mais à l'époque Heroku CI était chouette parce que nous ça nous a permis vraiment de faire cette migration très facilement avec peu de maintenance induite par la plateforme Heroku forcément. Et vu qu'elle était totalement intégrée avec GitHub, au final on n'avait même plus besoin d'orchestrateurs, de CI à proprement parler, et Roku CI faisait tout pour nous dans le sens où on venait récupérer nos diffs directement de GitHub et lancer des builds de tests directement derrière, et venir nous notifier ensuite des résultats, donc c'était plutôt chouette. d'ailleurs ça existe toujours du coup et recoussé à je ne crois et ça quand je suis zéro coup mais déjà vu qu'il ya une partie s'il ya et donc je passe à côté ouais c'est pas très très connu mais ouais du coup et recoussé du coup ça nous a ça nous a bien aidé à justement à kickstarter un peu vraiment la migration depuis jenkins est arrivé à se concentrer vraiment sur nos core features et pas passer trop de temps justement en maintenance d'une infrastructure de CI, etc. Mais du coup, les problèmes...
- Speaker #0
Je note, parce que je trouve ça vachement bien ce que tu dis, je note pour les gens qui passent beaucoup de temps, surtout dans les petites boîtes, à maintenir des infrastructures de CI alors que ce n'est pas leur cœur de métier, utiliser des trucs en ligne, c'est quand même vachement bien et ça coûte moins cher que de passer des heures à maintenir ton Jenkins ou autre, ou tes runners, pour économiser des fois 3 francs 6 sous parce qu'on... fait c'est un boulot de monstre à ça a du sens à votre échelle maintenant aujourd'hui parce que clairement il faut des gens de façon qui passera plein temps mais clairement c'est un truc assez smart de faire ça je pense ouais et puis même propre à ce que tu dis là à l'instant justement on
- Speaker #1
est enfin doté à vachement grossi du coup on a aussi maintenant une équipe dédiée à l'automatisation à la développeur expérience à la qualité etc et c'est super cool mais même aujourd'hui après avoir construit plein d'outils très custom pour Doctolib aujourd'hui maintenant on essaie de réévaluer un peu tous ces outils et de voir si on n'a pas des solutions externes en fait qui pourraient répondre aussi à nos besoins parce qu'en fait on réévalue aujourd'hui le coût de maintenance de certains de nos outils qui aujourd'hui nous coûte cher forcément même si on a une équipe qui répond on fait la différence différenciation entre ce qu'on appelle le build et le run où le build va concerner tout ce qui est nouveau projet qui va répondre à une roadmap et le run qui est toute la partie de maintenance forcément et qui nous incombe après qu'on ait délivré quelque chose en production et on essaie justement de garder un niveau de run enfin une part de run vis-à-vis du build qui est soutenable et qui soit la plus petite possible in fine pour pouvoir se concentrer davantage sur l'apport de valeur pour nos customers qui sont les développeurs à Doctolib du coup.
- Speaker #0
et pas se faire manger petit à petit par des systèmes qu'on met en place mais qui au final nous grignote tout notre temps et on est on n'est plus de temps à délivrer quoi que ce soit moi ça veut dire qu'en fait je fais même le choix à chaque fois de même du build versus bail quoi c'est quand tu as une solution tu vas regarder si tu peux l'acheter plutôt qu'il a la run après du coup derrière mais pas à
- Speaker #1
zapper le temps de build si surtout si le temps de run après peut être très léger exactement c'est exactement ça et ouais donc même aujourd'hui avec des équipes à proprement parler faites pour ça on réévalue toujours bien ces éléments pour revenir juste à Heroku CI du coup Heroku CI du coup nous a pas mal aidé à nous concentrer davantage sur notre core produit et arriver à un temps en fait sur Heroku CI où en fait notre stack a grossi notre stack de tests aussi donc ça s'est complexifié forcément avec plus de développeurs qui travaillent, plus de builds qui sont demandés, etc. avec une feedback loop qui a forcément aussi pris un petit coup et qui s'est étendue. Et du coup, on a dû partir un moment de Heroku CI pour deux raisons principales. Premièrement parce que Heroku CI est... était parfait pour un monde où on respecte toutes les conventions et on ne sort pas des sentiers battus on va dire. Et Doctolib, plus on agressif, plus on est sorti de certains sentiers forcément pour aussi couvrir nos besoins métiers. Et du coup Heroku CI ne nous a pas permis vraiment d'avoir un champ de configuration assez suffisant pour soutenir notre charge tout simplement. Et en plus de ça, ça devenait de plus en plus cher, forcément, qui gérait tout pour nous à l'époque. Et donc la combinaison des deux, au final, nous a apporté à faire le choix de partir de Heroku CI.
- Speaker #0
Mais partir où ?
- Speaker #1
Oui, pardon ! Et du coup, on est partis de Heroku CI, et on a fait le choix à l'époque, pour la partie CI en tout cas, de sélectionner Team City. qui est un soft assez ancien maintenant il me semble, je crois que c'est dans le début des années 90, la première version de TeamCity. Et en test execution, on est parti sur quelque chose qui s'appelle Cirrus, mais qui est custom made alors. Il y a quelque chose qui s'appelle Cirrus et qui est aussi un système de CI qui est open source et on s'en est rendu compte après, on s'en est mordu les doigts. Mais on a construit quelque chose qui s'appelle Cirrus pour la partie test execution. propre infra de l'exécution de tests et qui pour le coup était très révolutionnaire à doctolib parce que Cyrus était composé de clusters Kubernetes donc on a fait le move sur Kubernetes pour notre CI à cette époque là et donc cloud environment Kubernetes enfin tout plein de tout plein de nouvelles notions à l'époque en tout cas et c'est ce qui nous a permis justement de d'avoir plus de configuration, d'aller pouvoir faire des améliorations aussi qui nous ont permis de réduire les coûts drastiquement de ce qu'on faisait tourner au quotidien sur notre série. Et on en a été très très contents pendant très longtemps.
- Speaker #0
Mais c'est plus le cas,
- Speaker #1
du coup tu t'as normi du coup.
- Speaker #0
C'est fini Team City et Sirius alors ?
- Speaker #1
Ouais, Team City était bien, en fait Team City était cool. parce que c'était très facilement configurable. C'était configurable, vu que c'est un visio software, il y avait pas mal d'options et on pouvait faire vraiment tout ce qu'on souhaitait. Le problème, c'est la manière dont on rendait ça configurable, c'était à travers du Kotlin, et nous, c'était assez loin de notre style, et nos développeurs, forcément, étaient un peu perdus à chaque fois qu'ils devaient mettre les mains dedans, ce qui ne favorisait pas vraiment l'adoption de TeamCity. Donc ça c'était un premier sujet. Et ensuite, le Cyrus, notre infrastructure d'exécution de tests, en fait elle nous a supporté vraiment pendant plusieurs années. On a été très contents, on a mis par exemple en place l'exécution de nos tests, pas sur des EC2, mais sur des EC2 spots, pour justement aller réduire nos coûts, donc les spots instances. Pour ceux qui ne connaissent pas, c'est simplement des instances que AWS nous loue à un coût très réduit, entre 30 et 50% du prix en moins, à condition qu'ils puissent reprendre la machine sous deux minutes, avec une notification avant les deux minutes. Et donc d'avoir cette possibilité de pouvoir réduire nos coûts. En contrepartie, d'ajouter un peu de résilience de notre côté pour faire en sorte que si une machine qui faisait tourner des tests est reprise par AWS, qu'on puisse rejouer les tests qui étaient en train d'être exécutés ou qui allaient être exécutés sur ces machines-là. Donc on avait fait ce trade-off à l'époque et c'était vraiment très chouette, ça nous a permis de drastiquement réduire nos coûts. Le problème, toujours, forcément, c'est que petit à petit, au début on avait un cluster Kubernetes. pour faire tourner nos tests. Et puis, avec le temps, on a eu plus de développeurs, plus de tests, etc. Donc, on a mis en place plusieurs clusters Kubernetes. Et puis, de un, on est passé à deux, puis à trois, etc. Et puis, on est quasiment arrivé à une dizaine de clusters Kubernetes avec une grosse charge sur chaque cluster. Et ça devenait assez lourd, aussi bien en termes de maintenance, mais aussi bien en termes de coûts. Alors, de coûts, pas forcément en termes de... d'exécution de tests sans on les connaissait déjà et c'était relativement linéaire mais plutôt en termes de statique costes qui était induit en fait par par avoir des clusters uks qui tourne sur sur aws et ça forcément bas mis bout à bout à l'année basse à coûter quand même quelques billets et donc forcément on a dû s'en détourner au bout d'un moment. Et arrive enfin, du coup je fais l'histoire complète, arrive enfin du coup le dernier contender et le plus récent. Côté CI, on a remplacé TeamCity par un autre outil qui est GitHub Action. En fait on est client GitHub depuis que je suis à Doctolib, on est sur GitHub en tout cas. et pour la partie github action depuis quelques années est ce qui est cool avec github action basse et que c'est assez stricte ford pour nos développeurs dans le sens où bas connaissent github ils connaissent l'interface pour aller créer des workflow des jobs peu importe en fait c'est du gamin gamin la c'est
- Speaker #0
pas du cote l'île déjà et c'est vrai que tout à l'heure c'est pas intéressant parce que pour les gens qui pour moi bossent dans le design de dev tous les compagnies quand tu faire un choix de techno qui est Tiens, on va leur coller du Kotlin ou du machin, tu limites quand même beaucoup ton audience en termes de... Alors c'est sûr que c'est beaucoup plus simple de faire du Kotlin que du YAML, ça c'est pour un positif. Tu peux faire sûrement tout et n'importe quoi, le problème c'est que du coup la cour d'aventissage et la barrière d'entrée est beaucoup plus haute et que si tu n'as pas des gens motivés de l'autre côté, c'est plus difficile quoi. Donc on a l'avantage de faire du YAML.
- Speaker #1
C'est exactement ça, ouais. Et puis le YAML, on aime, on n'aime pas, après ça reste quand même assez explicite et facile. facile d'accès comme tu le dis donc forcément en passant sur GitHub Action en fait on a multiplié le nombre de pipelines automatisés en fait qu'on avait tout simplement parce qu'il y a eu une adoption tout de suite qui s'est faite et voilà donc toute la partie CI orchestration est gérée aujourd'hui par GitHub Action et pour la partie test execution on a du coup On a arrêté Sirus avec ses clusters Kubernetes. Et puis le constat, c'est que ça devenait trop conséquent à maintenir. En termes de static cost, c'était plus soutenable non plus. Donc du coup, on s'est tourné toujours vers AWS, mais cette fois vers le cloud. Et du coup, de ce côté-là, on a pris le parti d'aller sur du serverless, cette fois-ci, et d'arrêter... de maintenir des clusters tout simplement. Et du coup on fait du serverless, on lance des tâches en fait, on déclare une size de tâches pour exécuter nos tests, et en fait nos tests tournent sur X tasks par build que les développeurs requestent directement. Ce qui est cool aussi c'est que ce serverless supporte également les spots, donc du coup on a du serverless en spot et ça c'est le meilleur des deux mondes parce qu'il n'y a pas de maintenance à proprement parler il n'y a pas de static cost vu que c'est du serverless les seuls inconvénients vraiment qu'il y a à ça c'est le côté interruption vu que c'est du serverless on n'a aucune notion de type d'instance ou quoi que ce soit on demande juste... j'ai besoin de temps Et le problème c'est que du coup vu qu'on ne sait pas ce qui se cache derrière, il faut souvent arriver à trouver au bon endroit, au bon moment, les instances ayant le plus, enfin les tâches ayant le moins d'interruptions possibles. Et ça du coup c'est un jeu quotidien pour trouver en fait ce juste équilibre entre coût et interruption et donc du coup reliability pour nos tâches d'exécution au final.
- Speaker #0
c'est quel service que tu utilises chez AWS pour faire ça du coup ?
- Speaker #1
je ne connais pas tous les services AWS ouais alors c'est un combo batch et forget et forget spot du coup et voilà on en est très content pour le moment ça tourne vraiment très bien et ouais voilà là ça va faire un peu plus d'un an maintenant qu'on a fait cette migration sur du serverless du coup tu exploses ça avec GitHub Action en fait ? ouais en fait ce qui se passe c'est que sur github on va avoir toute la partie docker build exécution de certains tests statique etc on a quand même l'exécution de nos tests fontaine qui sont réalisés directement sur les runners de github mais toute la partie au final exécution donc plus back n on va dire et n2n va se réaliser du coup sûr sur un bus sur sur ce phare get spot là dont on vient de parler et du coup au final dans nos workflow on a simplement en fait toute la partie en amont donc vraiment le build avec le build de l'image etc qui se réalise et ensuite on a nos workflow qui contacte en fait notre notre infras notre infras nimbus pour venir à exécuter en fait les tests directement quand
- Speaker #0
tu as un job qui a interrompu comme ça du coup puisque c'est du spot tu es en charge de le relancer toi même ou c'est à w si on occupe
- Speaker #1
non c'est bien sûr à nous d'aller le faire la partie résilience ouais bah là ça dépend vraiment de la workload qui est mise à disposition déployée sur les tâches donc la résilience elle est à faire côté software de l'autre côté nous on a un système de queue qui en place tout simplement et donc en fait les tâches des piles en fait des tests file depuis une queue et si une tâche se fait se fait notifier qu'elle se fait reprendre qu'elle se fera reprendre dans deux minutes Simplement on vient recueillir le test file dans notre queue et puis ensuite il s'est repris par une autre tâche etc.
- Speaker #0
Moi je pense à un truc parce que tu parles de ça, du coup j'imagine que ça augmente la latence potentielle du résultat de test pour les développeurs ?
- Speaker #1
Oui totalement.
- Speaker #0
C'est un problème ?
- Speaker #1
Alors oui c'est un problème, l'interruption en soi n'est pas vraiment un problème parce que j'ai pas les chiffres exacts mais on a quand même... quelque chose comme 400 tâches différentes on va dire à chaque fois qu'un développeur demande un build d'exécution des tests donc sur 400 tâches l'impact d'interruption d'une tâche est assez faible et on a un taux d'interruption sur toutes les tâches au quarter qui est en dessous du pourcent donc on reste quand même dans la limite du raisonnable mais bien sûr ça a forcément un impact sur la feedback loop mais aujourd'hui c'est pas pas ça honnêtement qui nous impacte le plus c'est plutôt le temps du docker ville c'est plutôt le temps de du build des assets fontaine qui aujourd'hui aussi est considérable et c'est ça qui vient réduire au final aujourd'hui la feedback loop et c'est ce sur quoi aujourd'hui l'équipe aussi travail pour essayer de trouver des améliorations pour réduire justement le le temps de build en amont de l'exécution des tests surtout que tu as hâte
- Speaker #0
Tu as mentionné tout à l'heure que vous avez près de 90 000 tests, donc là aussi tu as un truc, parce que si tu as 90 000 tests, alors à moins de tester des trucs très basiques, je pense que ça prend quelques minutes, quelques dizaines de minutes de tous les lancer, du coup tu ne peux pas tous les lancer.
- Speaker #1
Oui, exactement. On est obligé de faire des compromis, alors on essaie de faire le moins de compromis sur la qualité, ça c'est sûr, mais en termes de compromis qu'on peut évoquer, on a des mécanismes de... de test selection qui sont en place et qui nous permettent au final entre le domaine des branches de pool request et de la branche main chez nous on va avoir une test selection qui se fait sur toutes les branches de pool request versus on va tout lancer par exemple sur la branche main la branche principale de notre repository et donc sur les branches de pool request on a deux mécanismes qui existent aujourd'hui on a un premier mécanisme qu'on appelle CITP pour CI test speaker, qui est un système custom qu'on a fait chez nous. C'est un système qui, à la base, on lance tous les tests plusieurs fois par jour avec un coverage qui est enabled et qui est activé. On stocke ce coverage, ces données de coverage, quelque part. Une fois qu'on a ces données de coverage, on... On vient reverse ces données de coverage et les utiliser pour que quand un développeur ou une développeuse modifie par exemple le fichier X, on sache que ce fichier X est relié à tous ces tests files grâce aux données de coverage précédemment computées. Et donc on lance les tests files correspondant aux fichiers uniquement modifiés sur la branche de pull request. Ça, ça nous permet de faire des belles réductions.
- Speaker #0
Déjà en terme de feedback loop forcément, parce qu'on vient pas relancer tous les tests, les 90 000 tests, donc ça c'est hyper positif.
- Speaker #1
Tu connais le temps d'exécution des 90 000 tests, juste pour référence ?
- Speaker #0
Ouais, alors en fait on a, donc ça c'est sur les branches de pull request, mais sur la branche main, on lance toujours tous nos tests comme garde-fou en fait, pour s'assurer que tout est là. Et donc... on a deux tests suite principal on va on va appeler test suite n2n et une suite non n2n et je n'ai pas les chiffres exacts encore une fois mais la suite n2n doit tourner autour d'une vingtaine de minutes un peu un peu moins de 20 minutes et la suite non n2n doit aux alentours des 16000 16 minutes quelque chose comme ça sachant qu'on a vu plus de tests unitaire que de tests n2n mais les tests n2n étant beaucoup plus lent, forcément, parce qu'on lance un navigateur, on mimique des interactions utilisateurs, donc forcément ça prend du temps. Forcément, la test end-to-end est un peu plus longue.
- Speaker #1
Donc tu paralyses, j'imagine, en masse, tout ce test-là.
- Speaker #0
Exactement, oui, oui, on a, je te l'ai dit, par suite, en fait, directement, on a quelque chose comme 400 tâches qui sont lancées à chaque fois.
- Speaker #1
Donc le build, si tu mets tout à la suite, c'est énorme.
- Speaker #0
Oui, l'infra, le nombre de tâches qu'on demande à chaque fois à notre cloud provider est phénoménal. C'est plus que notre environnement de production au quotidien. On a une plateforme de CI qui est bien plus conséquente en fonction des pics de la journée en termes de demandes de nos développeurs.
- Speaker #1
c'est rigolo du coup tu as ou est après ce que plus de skype prod finalement en termes d'infra de taille d'un frère de travail tu lances ce qui est pas étonnant si tu fais bien ton taf et tu lances beaucoup de tests et que tu potentiellement avec a beaucoup de tu peux calculer du coup le prix en dollars de la chapeau le request c'est bien ouais exactement ça
- Speaker #0
alors c'est un prix alors il ya un truc aussi on a parlé de spot instance alors en fait spot est une bourse à deux une bourse d'échanges de de compute power littéralement. Du coup tout le leftover de EC2 de manière générale ou de services serverless classiques revient en fait à spot et donc en fait en fonction de la demande sur les services plus classiques comme EC2 ou des services serverless plus classiques, en fait le prix de spot instance ou task va varier. Et donc il y a littéralement un prix, alors je crois qu'il est, c'est un prix horaire, enfin un prix qui est updaté heure par heure. sur tout ça et donc en fonction de la journée des choses comme ça et de la périodicité en fait tout simplement on va avoir des fois des journées avec plus d'interruptions et ça va nous coûter aussi plus cher versus d'autres jours ça va être moins cher je prends par exemple l'exemple de gros événements sportifs ou des fois on va voir un spike d'interruption ou une petite augmentation des coûts etc donc des fois c'est marrant de voir cet impact là aussi sur nos quoi ok ouais du coup
- Speaker #1
Il faut gérer la bourse en parallèle si tu veux optimiser le coût des développeurs.
- Speaker #0
Exactement. D'ailleurs, sur ce sujet précis, on a mis même un monitoring en place pour s'assurer qu'on demande au bon endroit à chaque fois nos tâches et qu'on demande à chaque fois l'endroit où il y a le moins d'interruptions et où la région est le moins chère à chaque fois. qu'on puisse arriver à une cia est vraiment efficiente en termes de coups quoi et de réélab iti pour avoir le moins d'interruptions possible quoi l'arbitrage en permanence en fait sur ce que tu fais pour être sûr que exactement c'est ça et on est capable facilement de sélectionner à travers nos commandes ça peut être un nouveau métier que tu as inventé ce broker de 6e finalement c'est assez passionnant le monde de la spot instance c'est assez fou mais mine de rien il ya pas mal Il y a des belles économies à réaliser en termes d'infra. Ça demande forcément... Alors, c'est peut-être pas adapté à tous les workflows de travail, mais ça permet vraiment d'être cost efficient au maximum sur pas mal de sujets. Ok,
- Speaker #1
c'est cool, super intéressant. Je ne sais pas, j'ai rarement vu des équipes aller aussi loin dans l'optimisation en termes de coûts, de distribution de tests, etc. Donc, c'est super intéressant. Et le côté... test runner dont tu parlais est super smart on voit ça de plus en plus je pense que c'est une super technique malheureusement pas assez de gens ont mis en place et qu'on sait avoir des outils pour faire ça C'est super cool, on bosse un petit peu là-dessus en interne maintenant et c'est vrai que c'est un bon truc je pense sur lequel il y a beaucoup de choses à faire. C'est une sorte de compromis de trade-off, tu relances les tests sur main à la fin pour voir que ça fonctionne toujours bien. Tous les compromis que tu fais dans un CI en permanence, que ce soit de ne pas tout tester, les gens qui font du monorepo connaissent ça très bien, de ne pas tester tous tes tests, toutes tes parties de tes projets dans ton repo parce que tu ne peux pas tout lancer sinon c'est trop. trop long etc tu fais tout le temps des compromis sur ta feedback loop etc avec le coup de CI et tout petit point petit et c'est un vrai sujet parce que parce que il faut toujours gérer des compromis à tous les niveaux en fait de toutes les étapes de ton cycle et personne ne fait toujours les mêmes parce que tout le monde a des contraintes différentes un historique est différent donc ça c'est assez rigolo de voir ça du coup tu parlais de relancer les tests sur main et je sais que vous faites aussi pour une des raisons qui est de choper les flaquites à ce temps ouais
- Speaker #0
peux rater dans les pères ou dans les pères partout en fait en fait on a ouais c'est autour des tests va juste pour revenir sur un élément dont je parlais avant en parlant de compromis en termes de test selection ont aussi testé un autre truc récemment on a appelé au bts pour ownership based test selection c'est très bon marketing je vois sur le nom des proères ont déjà fait C'est vrai, on adore les acronymes Adoctolive, si vous adorez ça, possible Adoctolive. Non, ça devient des fois un peu cocasse comme situation avec nos acronymes, mais en gros, on a testé un nouveau compromis en termes de test selection qui était couplé avec notre CI test picker dont on a parlé juste avant, qui était basé sur des notes coverage. Et le trade-off, c'était de se dire, en fait, les fichiers modifiés dans la pool request appartiennent à telle équipe. Donc le fichier X qui a été modifié dans la paire appartient à l'équipe Y. Dans ce cas-là, on va se dire, on essaye le compte premier de se dire, très bien, c'est un fichier de l'équipe Y qui a été modifié, je vais lancer uniquement les tests files de l'équipe Y. Et quand je dis les tests files de l'équipe Y, c'est uniquement les tests files de l'équipe Y qui se retrouvent dans les données de coverage de CI Test Speaker. Donc c'est un peu un cross des deux. Là dessus on a essayé, on essaye toujours de le faire tourner, le problème c'est qu'on a quand même pas mal de déconvenues avec ce compromis Parce qu'aujourd'hui Doctolib depuis un bon moment c'est un gros monolithe, de moins en moins on essaie de le découpler de plus en plus Mais le fait que ce soit un gros monolithe on a beaucoup de couplages Et au final, lancer les tests que d'une seule équipe, ça marche bien pour des équipes qui sont découplées, qui ont un scope technique qui est très découplé et qu'on peut facilement mettre de côté. Alors que dans un monde où tout est couplé, forcément si on ne s'occupe que du périmètre d'une équipe, mais où tout est couplé, on oublie de tester une bonne partie. Et dans ces cas-là, on se retrouve avec forcément des... des tests faillures un peu plus tard, typiquement sur la mainbranche, et dans ces cas-là, ça pose problème, parce que notre mainbranche devient rouge, et là, ça devient compliqué, il faut comprendre pourquoi, etc. C'est quelque chose qui est embêtant. Donc, pas encore super satisfait de ce système-là, mais on essaie de le travailler encore, voir si on peut l'améliorer, et si on n'y arrive pas, on le droppera tout simplement. Voilà, juste pour dire qu'on... on essaye d'autres alternatives.
- Speaker #1
C'est une bonne idée, mais c'est vrai que le couplage est super difficile parce que tu le vois dans les équipes qui vont du monorepo au multirepo, tu as toujours un couplage, donc des fois il est implicite, des fois il est explicite, et même si tu as des équipes qui sont indépendantes, qui gèrent chacun leur microservice dans un repo, de toute façon tu as du couplage à un moment, parce que les gens utilisent le service entre eux, donc tu vas avoir des contrats sous forme d'API, de ce que tu veux, si tu ne testes pas les couplages, en disant de toute façon qu'elle sera pas le contrat tu as forcément un truc qui peut se caser un comportement des piailles un schéma ça peut se valider à manière un peu programmatique mais un comportement des piailles pas forcément si tu as des tests tu peux les changer donc en fait tu as toujours ce truc là ne pas tester tout ensemble c'est toujours un compromis quel que soit ton architecture derrière parce que tu fais juste le pari que non mais c'est bon ça va passer parce que eux ils vont pas faire modifier le truc qu'eux utilisent ou d'une manière ou d'une autre et c'est super difficile donc faut arriver à trouver ceux qui sont plus ou moins couplés de près ou de loin Mais il peut aussi y avoir des chaînes de réaction de plusieurs services qui s'enchaînent et que le changement de un ou de la troisième chaînage, en fait, ça casse le truc et c'est super compliqué. Dès l'instant où tu ne se lances pas tes 90 000 tests, tu fais des compromis. Donc après, effectivement, je pense que votre recherche permanente des meilleurs compromis, c'est un vrai sujet. Et c'est super intéressant de tester les nouveaux trucs pour voir si tu peux optimiser un peu à droite, à gauche, et d'avoir un truc qui est meilleur en fait.
- Speaker #0
Oui, d'ailleurs là-dessus j'ai l'impression que le marché est aussi un peu en train de réagir sur ce sujet de test selection et de trouver les bons compromis à chaque fois pour valider et s'assurer de la qualité. On a vu apparaître quelques boîtes comme Launchable ou encore Datadog qui est sorti il n'y a pas très longtemps. un outil de test selection et du coup c'est potentiellement des trucs qu'on ira essayer de poker dans le futur pour voir si justement on peut s'appuyer sur sur ces outils là un peu externe et du coup arriver à retirer un peu cette maintenance aussi de ces systèmes là qu'on a chez nous et qu'on pourrait potentiellement déléguer quoi je pense que c'est une bonne idée de ce que tu disais au début de toujours faire attention à le build,
- Speaker #1
le run et de minimiser la maintenance pour vous, c'est d'avoir des outils externes qui fonctionnent c'est toujours une bonne idée, si le coût est moindre et on parlait du coup des flakitests tout à l'heure, c'est un sujet je pense chez vous aussi, comme chez tout le monde on va pas se mentir ouais,
- Speaker #0
la boîte qui me dirait qu'elle a pas de flakitests je me méfierais à deux fois elle a pas de développeurs du coup c'est ça forcément avec 90 000 tests on a forcément du flakitest on en a même pas mal du coup on a aussi pas mal d'outillages et de process tout autour de ce qu'on appelle le... Alors je ne vais pas ressortir un acronyme, mais tout ce qui est autour du test lifecycle management, on va dire, tout autour de la vie du test.
- Speaker #1
Le TLM comme on dit chez nous.
- Speaker #0
Non, il n'y en a même pas d'acronyme là-dessus, j'abuse. Merde ! Mais ouais, on a quand même pas mal d'outillages autour. Autour des FlakyTest, on a plusieurs outils. On a un premier outil qu'on appelle le FlakyDetector, et qui lui est un tool qui se lance automatiquement sur tous les builds demandés par les développeurs pour aller détecter si un test est ajouté ou modifié sur le commit d'un développeur. le flaky detector va se trigger et va prendre les tests ajoutés ou modifiés, les faire tourner dans un environnement X fois, nous c'est 100 fois chez nous par exemple, un test est ajouté sur l'APR, le test est tourné 100 fois dans un environnement bien isolé, et provoquer un feedback aux développeurs, aux développeuses, en disant que le test a été rouge, a failé, on va dire, X fois sur 100. Si 0 fois sur 100, on part du principe que le test est relativement pas ou peu flaky. Dans ce cas là, le RequireCheck pour merger dans la branche main est vert, donc on laisse merger. En revanche, si on a du rouge, dans ces cas là, de nos jours, on va même forcer les individuels contributeurs à retravailler leurs tests. ne pas laisser entrer de la flacquiness dans la codebase de manière à ce qu'à terme on n'ait plus du tout de flacquiness dans la codebase. C'est un change qui est l'Automatic Flaky Detector, c'est un change qu'on a introduit très récemment. En fait, pendant plusieurs années l'outil existait, mais il était uniquement informatif. Et puis là, récemment, on a décidé de le rendre vraiment Required. pour pouvoir merger dans la main branche et ce qui va nous permettre de fermer le robinet de la flakiness et donc de réduire nos flakitests à terme ça sera le titre de l'épisode,
- Speaker #1
fermer le robinet de la flakiness je pense que ça va pas être mon titre j'aime bien,
- Speaker #0
ça me plait et du coup c'est pas un tool qui est parfait parce que c'est que sans try sans essai d'exécution du test c'est pas parfait forcément et puis alors on... on pourrait en parler des heures, mais il y a plein de types de flakiness. Isoler un test et le faire tourner 100 fois, effectivement, ça permet d'éliminer la flakiness qui se loge au sein du test même. Mais pour tout ce qui est flakiness, qui dépendrait d'un ordering au sein du test file ou d'un service externe avec un test non hermétique, des choses comme ça, forcément, notre automatique flaky detector ne viendrait pas catcher ça. Mais on pense quand même que c'est une action qui va dans le bon sens. Ça ne catche pas tout, mais on... s'évite déjà une grosse partie de la kinès en introduction de la kinès dans notre code base et donc et donc on est content là dessus quoi c'est un bold statement vers la qualité en tout cas qu'on essaie de faire c'est vachement bien mais je pense que tu peux pas vraiment avoir fin
- Speaker #1
Je pars du principe que tout est flaky, le seul... Pas flaky, ça veut dire que tu aurais 0%, mais le 0% n'existe pas, parce que tu peux toujours avoir, tu sais, une éruption solaire qui va changer un bit dans la RAM et ton test devient flaky. Et ça, tu peux bien y faire. Donc en fait, à partir de là, tu sais que le taux de 0% n'existe pas, que tu peux avoir du 0, 0, 0, 0, 0, 1% en cas d'éruption solaire, mais après, c'est où est-ce que tu mets le seuil, en fait, finalement, de cette flakiness. Et ouais, effectivement, je pense que le mettre le plus loin... Si tu prends des trucs qui sont à 50% flakiness, c'est sûr que... arrêter de l'émerger mais bon si tu descends vers des trucs qui paye une fois sur dix mille bon bah c'est chiant c'est pas très grave une fois sur cent mille on n'en parle pas mais voilà c'est vraiment d'arriver à je pense petit à petit diminuer la barre et d'avoir ce mécanisme de tester les nouveaux tests ou les tests qui sont modifiés etc ça fait un peu partie du test sélection etc je trouve ça vachement bien d'avoir ce côté là pour vraiment être sûr que tu continues d'améliorer la qualité tu les laisses pas rentrer sur son truc je ne pensais pas beaucoup d'équipes qui ont pour le coup nous on n'a pas ça chez nous mais j'aimerais bien qu'on ait ça aussi parce que c'est un pas qu'on est de faquitas mais parce qu'en fait c'est chiant de le voir après en fait ça ralentit tout le monde c'est vraiment l'impact que ça derrière sur les équipes la frustration des développeurs peut-être pas développer un expert installeur c'est un truc qui est vraiment relou quand des développeurs et à l'équipe d'à côté qui a mis des tests pour pourri qui en fait t'empêche de manger ta paire et tu dois faire des rites rares et permanents que de ça c'est quand même casse-fille ouais exactement et là dessus en fait pour
- Speaker #0
Vu que c'était un check informatif, l'automatic flaky detector, et qu'il est passé en required il y a quelques temps, forcément on pensait avoir un peu de friction, on a eu un peu de friction à l'arrivée de ce required check, parce que ça allait demander plus de la part d'un individual contributor. Mais pour essayer de faire comprendre l'impact des flaky tests à l'équipe technique, On a essayé de prendre l'approche statistique et de chiffrer l'impact de nos flakie tests aujourd'hui sur nos systèmes de CI et sur leur feedback loop. Et in fine, long story short, je ne vais pas passer sur tous les détails des calculs statistiques, mais on a démontré et on a prouvé à l'équipe technique in fine, tous nos flakie tests avec leur niveau de flakiness et le nombre qu'on en a, aujourd'hui chez nous à Doctolib, c'est comme si on faisait tourner nos exécutions de tests une journée en plus sur la branche master par semaine. Donc c'est comme si, vu que sur notre branche main master, on fait tourner tous nos tests sur tous les commits qui arrivent sur notre branche principale, et bien en fait, nos flaky tests, c'est comme si aujourd'hui, leur impact, on faisait tourner 6 jours sur 7 notre CI. donc ce qui est relativement très conséquent et c'est pour ça qu'aujourd'hui on essaie de trouver des actions qui sont un peu plus forcément contraignantes mais qui vont dans le sens de la qualité et qui s'assurent qu'on introduit pas de nouveau des choses qui pourraient nous ralentir ou nous coûter plus cher
- Speaker #1
Et tu fais comment du coup pour, tu parlais de calculer des statistiques etc, vous avez un outillage particulier pour tout ce qui est observabilité, reporting ce genre de choses ou vous faites ça un peu avec ce que vous avez sous la main ?
- Speaker #0
custom ou alors en termes de web observabilité etc sur toute cette partie là initialement on a tout construit from scratch vraiment on a une super équipe data avec qui on travaille vraiment main dans la main qui nous a construit un data mart pour les aider à attirer des stats hyper intéressante avec un tracking de deux tests par un niveau de flaquines des catégorisations etc donc vraiment top problème c'est que c'est aussi En termes de data qui est produite de nos systèmes d'exécution de test de CI au quotidien, c'est hyper volumineux. Et donc les data marts sont aussi très conséquents à gérer, à maintenir, etc. La moindre évolution, ça demande quand même pas mal de travail. Aujourd'hui, on essaye petit à petit de s'intégrer de mieux en mieux à Datadog CI, qui propose la branche Datadog CI. où ils ont une branche directement pipeline visibility et test visibility avec justement sur la partie test visibility toute la gestion de flakiness, de reporting de flakiness etc qui moi en tant qu'utilisateur quotidien je trouve vraiment super parce que ça permet justement de corréler très facilement quand est-ce que le test a été flaky pour la première fois, quand est-ce qu'il a flaked la première fois sur quel commit autre il a flaked retrouver la top liste des erreurs message du flaky test lorsqu'il a fail etc et ça c'est vraiment top parce que du coup nous en plus de ça on a pu très facilement Avec mes petites mains de product manager qui connaît un petit peu la technique, j'ai pu facilement construire des dashboards, pouvoir provide à chaque feature team un feedback sur leurs flaky tests, les trier par impact, etc. Et donc, ça leur permet directement aux équipes de prioriser les flaky tests qu'ils doivent fixer. Et ça, c'est vraiment hyper cool. comme outil parce que du coup nous on se concentre uniquement sur la valeur ajoutée qu'on peut donner aux équipes et puis tout le tout le bac n avec la gestion de la data l'ingestion le tout ça en fait et gérer pour nous et on a une belle vieille en plus pour
- Speaker #1
gérer tout ça et à provoquer nos équipes donc c'est vraiment très chouette donc un bon outil qui vous résout pas mal de problèmes à ce niveau là quoi de faire tout le boulot pour vous de gestion des données de reporting au final exactement
- Speaker #0
C'est exactement ça. Et puis il y a un process aussi dont je n'ai pas parlé juste avant, mais j'ai parlé des flakies et notifier les équipes, etc. Et ne pas accepter l'introduction de nouveaux flakies. On a aussi un autre processus qui est encore un peu plus dur, qui est de dire si le test qui est flakie devient vraiment trop impactant. que ce soit pour l'équipe ou même la tech team de manière générale parce que ça impacte tout le monde in fine au bout d'un moment si le test devient vraiment trop impactant on décide carrément de skipper le test et donc de dire que ce test est vraiment un unradiable on ne peut pas vraiment lui faire confiance au bout d'un moment s'il dépasse un certain threshold on va simplement le skipper le skipper c'est simplement arrêter de le faire tourner et là on notifie l'équipe que un de leurs tests a été skippé Et donc si skippé, l'équipe a aussi une policy là-dessus à tant de jours pour fixer son test skippé. Et donc au-delà de cette période-là, on dit tout simplement que ça fait un mois que le test a été skippé par exemple. Ça fait donc un mois qu'on a perdu cette coverage. C'est potentiellement un mois aussi où cette coverage n'était peut-être pas nécessaire, parce qu'elle est couverte aussi par d'autres tests. c'était pas si important et dans ces cas là on décide de supprimer le test vraiment pour aussi incentiver les équipes à supprimer l'équipe en fait là c'est non mais c'est normal aussi chaque équipe à son coeur métier ses priorités et c'est les flac test je peux comprendre que ça soit pas forcément hyper sexy pour toutes les équipes nous on essaie de les in cn tv au mieux les notifier au mieux pour que justement on n'est jamais à faire ça en ligne finée et que ça se passe dans le meilleur des cas, que l'équipe fixe. Mais voilà, ça peut nous arriver de temps en temps de supprimer un test qui n'a pas tourné depuis un mois.
- Speaker #1
Il faut quand même rappeler, on parle de flakie test parce qu'on imagine tout le temps que c'est le test le problème, mais des fois ce n'est pas le test le problème, c'est le code aussi, il faut faire attention à ça, parce que quand tu fais ce genre de choix, pour moi, c'est que tu parles de le test En fait, ça marche, c'est juste le test qui est bugué, on va virer le test. Mais en vrai, des fois, les tests sont bons, c'est juste que, par exemple, tu as une race condition dans ton code, et en fait, le code n'est pas bon, et le test attrape le problème. Il ne faut pas toujours jeter la faute sur le test. Des fois, c'est du flaky code détecté par un joli test qui marche très bien. Il faut faire gaffe à ça pour les gens qui ont tendance à dire Ah, c'est cool, on va suivre les flaky tests.
- Speaker #0
Alors attention, ce n'est pas ce que je dis non plus.
- Speaker #1
Non, bien sûr, mais du coup, je nuance ton propos.
- Speaker #0
Oui, tu le fais bien.
- Speaker #1
Il faut faire super gaffe parce que Parce que malheureusement, évidemment que le test n'est jamais la bonne idée, il faut bien regarder ce que tu dis, du coup tu le skis pendant un mois, mais c'est vrai qu'en vrai le vrai truc c'est qu'il faut regarder d'où vient le problème, il faut analyser un poil si effectivement le test est grossièrement écrit, et que évidemment il ne marche pas des fois, c'est pas trié pareil tout le temps, donc non, effectivement il y avait une mauvaise assumption qui était faite dans le test, et il faut le réécrire, le virer, peu importe, prendre une décision, mais il faut surtout faire gaffe que ce n'est pas forcément le test le problème, et que ça peut justement spotter un problème sous-jacent dans du code, et donc ça c'est... clairement ce que tu veux, il ne faut pas blâmer ce pauvre petit test.
- Speaker #0
Oui, 100%, je parle de supprimer des tests, etc., mais ce n'est vraiment pas quelque chose qu'on souhaite, c'est uniquement essayer d'incentiver nos équipes à fixer ces tests-là, ou le code qui est derrière. Et d'ailleurs, sur ce sujet-là, on a toute une série d'articles qui ont été postés sur le blog Medium de Doctolib, sur justement comment investiguer de la flacquiness, et que, in fine, il y a eu de l'en... Dans plusieurs articles, on trouve très souvent qu'il y a potentiellement un vrai bug qui se cache derrière le flaky test et que ce n'est pas juste, comme tu dis, un problème de test ou d'écriture du test. Donc oui, c'est hyper important de bien fixer la route cause et pas juste le test en question.
- Speaker #1
Il le perd pour pas bloquer ses petits camarades qui bossent dans le même repository, dans l'équipe à côté, ça c'est bien. Exactement. Faut être de bons petits camarades, c'est ça quoi. Du coup, on a pas précisé un truc tout à l'heure, on parlait des développeurs, mais du coup vous avez quand même une équipe qui s'occupe du CI à proprement parler, c'est quelle taille d'équipe en fait, c'est combien de personnes pour gérer tout ça ?
- Speaker #0
On a une équipe qui s'appelle Engineering Enablement, du coup, dont je suis l'un des product managers du coup, et alors on a à peu près une dizaine de personnes. qui travaillent sur tous ces sujets, sur 4 streams principaux Automation Platform, Quality Engineering, Release Engineering et Developer Experience On a une équipe qui gère ces 4 streams là qui continue de grossir au fur et à mesure des années et c'est très chouette à voir d'ailleurs Et en termes de profil, on a aussi bien des individual contributors qui vont être avec un background plutôt software engineer Ok comme des contributeurs qui vont plutôt avoir un background SRI, parce qu'en fait au final on se doit un peu d'être capable en tant qu'équipe d'intervenir sur de l'applicatif comme sur de l'infra. Je n'en ai pas parlé, mais tous nos systèmes sont terraformés, tout est automatisé, donc on se doit vraiment d'avoir cette double compétence et de pouvoir intervenir et aussi de discuter au final avec nos feature teams qui s'occupent. du monde applicatif alors on n'est pas forcément les les plus calés sur sur l'applicatif d'octolib tout naturellement mais on se doit pour se doit en tout cas de pouvoir discuter avec eux de comprendre leurs problématiques et aussi d'y répondre quand ils en ont besoin quoi donc c'est normal vous êtes un aussi en support pour pour
- Speaker #1
pour qu'ils aient un joli série qui fonctionne bien donc ça c'est quand même cool à cette échelle du nombre de développeurs pas forcément du support derrière au sens des gens qui aident un peu au sens de faire du support téléphonique mais au sens où il faut avoir des développeurs parce que ça devient un métier à part entière de gérer le CI et c'est un métier à part entière de faire l'applicatif donc il faut des gens des deux côtés qui bossent ensemble, main dans la main pour réussir, ça c'est important t'as fait un bon descriptif de l'historique, vraiment c'est assez cool de voir comment ça a évolué, par quoi vous êtes passé etc, et le nombre de chantiers que vous avez dû gérer pendant toutes ces années qui est quand même impressionnant entre les migrations et l'évolution, ça c'est assez normal de la tech et de QB voilà je pense que c'était... sacré chantier ça a dû s'occuper quelques années qu'est ce qui vous reste à ton sens aujourd'hui tu parlais du monde des flaquités c'est du fait que maintenant votre runner est obligatoire et tout donc ça dans la bonne direction qu'est ce qui vous avez des gros chantier des gros trucs sur lesquels vous dîtes à les prochaines grosses étapes c'est ça en fait à faire des gros sujets où ça roule assez fini je
- Speaker #0
pensais jamais fini très clairement aujourd'hui on est dans un milieu du coup initialement comme je t'ai dit on a un gros monolithe aujourd'hui on s'occupe vraiment d'essayer de de découpler ce monolithe mais on aimera bien et on s'est rencontré aussi comme ça initialement en termes de gros chantier nous on a on a essayé justement de setup une merck sur notre gros monolithe donc pour ça on a utilisé merdifi pour faire notre notre poc et voir un peu comment ça se comportait déjà et du coup l'année dernière ce qui est cool c'est qu'on a vraiment pris le temps justement de tester votre solution Et donc plutôt que d'essayer en live avec nos 400 utilisateurs d'un coup, parce qu'on sait qu'on a un très gros use case avec 400 développeurs, ce qu'on a fait c'est qu'on a essayé de répliquer notre gros repository au final, et notre gros monolithe, et on a essayé de répliquer le trafic en termes de commits, en termes de taux de flakiness, de nombre de tests flakies, etc. et de potentiellement d'interruptions, tout ce qui pourrait avoir une incidence sur le statut de nos... de nos builds d'exécution de test et au final justement de simuler du coup et de pluguer la merchq sur ce système qui était simulé, ce système virtuel. Donc nous on a appris plein de trucs et parce qu'on est persuadé que du coup la merchq c'est quelque chose sur lequel on veut aller parce que Nous on pense vraiment que c'est une manière d'improver la qualité pour tout le monde et de s'assurer que tous les changes qu'on introduit sur notre main branch, donc sur la code base générale, soient testés, soient validés et qu'il n'y ait pas de bypass et que ça soit clair et net pour tout le monde et qu'il n'y ait pas de priorité qui soit accordée à certains groupes de personnes. Que ce soit tout le monde est... est logé à la même ancienne et passe au même endroit. Et du coup, ce qu'on s'est rendu compte, c'est que, donc on a fait ce test-là en Q4 2023, nous ce qu'on s'est rendu compte, c'est qu'aujourd'hui, à l'époque en tout cas, on avait un taux de flakiness qui était trop important, avec des interruptions trop importantes, et du coup, ce qui s'est passé, c'est qu'en fait, on a simulé le fait que... Tout simplement, notre monolithe était trop lent à intégrer des changes avec une Merge Queue sur la main branche. C'est pour ça qu'aujourd'hui, depuis le début de l'année, on travaille, on a des chantiers pour réduire la flakiness. J'en ai parlé avec l'automatique Flaky Detector, typiquement, pour réduire aussi la feedback loop, etc., en termes de Docker Build, etc. Pour arriver justement à avoir une feedback loop plus courte, et donc la Merge Queue arrive à digérer plus de trucs simultanément. et qu'on puisse justement in fine arriver sur un système de MergeQ qui répondrait à un besoin d'amélioration encore et d'excellence en termes de qualité et c'est ce vers quoi on essaie de viser en tout cas et j'espère qu'on en reparlera vite ensemble
- Speaker #1
J'espère bien, mais effectivement ce que tu dis c'est intéressant c'est vrai que l'idée de la MergeQ c'est quand même de plus merger des pool requests qui sont potentiellement périmés, c'est à dire qu'on a plusieurs dizaines, enfin à la vitesse où vous allez je pense facilement plusieurs dizaines de commits de retard sur la branche... main et donc du coup qui ont pu avoir des résultats de test qui sont périmés littéralement et donc du coup de la tester avant mais du coup si tu retestes ça veut dire que tu relances le dé des flacquites est donc tu peux te retrouver à ne pas amerger la paire à cause d'un flacquite est de la faire retirer de la queue parce que le système va se dire bah effectivement ça ça marche pas je vais pas la merger donc le système fait office de filtre il filtre bien mais du coup si tu es indicateur de tests sont faux à cause de trop de flacquites est c'est un vrai problème parce que c'est simple la double peine dans ce cas là C'est ce que tu décris, effectivement c'est vraiment un souci de mettre ça en place quand tu as trop de flakitesses, trop de problèmes de failure de CI en amont, ça fait trop de filtres et c'est compliqué de merger du code. Ça améliore la qualité mais un peu trop du coup, ça peut être un vrai problème pour merger pour les équipes.
- Speaker #0
C'est ça, exactement. Et puis en autre gros chantier, on essaye toujours aussi de réduire la feedback loop. et du coup c'est de trouver des optimisations sur nos docker build, sur l'exécution des tests, donc toujours avec de la test selection, etc. Mais c'est aussi potentiellement continuer à retrouver une testing pyramide qui comprend de moins en moins de test end-to-end. Ça ne veut pas dire qu'on arrête d'en écrire, mais juste retrouver un niveau plus équilibré afin d'avoir des tests qui tournent plus rapidement et d'avoir des tests qui aussi... On n'a pas besoin de refaire 36 000 fois la même chose. Donc ça c'est aussi quelque chose qu'on vise dans le futur, et ça va totalement avec le découplage de notre monolithe qu'on est en train de faire. Enfin, pas notre équipe, mais que l'équipe technique est en train de réaliser. On a investi énormément sur le contract testing, notamment aujourd'hui. Donc voilà, c'est... Fin. améliorer la developer experience en essayant de leur provide un feedback le plus rapide possible.
- Speaker #1
C'est top, c'est de bons projets à avoir. Je pense qu'on a fait un super tour. Est-ce qu'il y a un dernier point que tu veux aborder Thomas ? Parce que moi je pense que là vraiment avec tout ce que tu as donné comme info, je pense que tout le monde peut rentrer à la maison et tweaker son CI pendant quelques semaines. Donc je ne sais pas si tu vois au niveau de Doctolib. Mais on n'a même pas tout ça chez nous et pourtant on est bien équipé donc vraiment c'est plutôt cool.
- Speaker #0
non bah un petit un dernier mot un dernier type de test dont on n'a pas beaucoup parlé c'est le lot de testing aujourd'hui existe à d'autres libres mais qui est peut-être pas encore à la hauteur de nos autres tests par exemple on fait du lot de tests périodiquement pour tester des évolutions des bums pas genre de version de deux langages par exemple des choses comme ça mais aujourd'hui on n'a rien de d'automatiser encore dans ce milieu là et je pense que c'est quelque chose aussi vers quand on doit aller en tout cas essayer de rendre ça accessible aux développeurs pour que eux mêmes en fait puisse au quotidien faire du mini lot de testing sans avoir à spawn un environnement complet qui fait huit fois la taille de la production pour faire des tests de performance par exemple Donc ouais, un sujet aussi intéressant, je pense, sur lequel on ira se pencher dans le futur.
- Speaker #1
Très bon sujet, que j'ai d'ailleurs abordé avec Mathieu Lerouet sur un épisode précédent de Mon Pipeline, où on parle justement de perfs, de tests, d'anciens et tout, et l'écouter si vous ne l'avez pas écouté, mais c'est vraiment ça, et je pense que c'est un truc super intéressant, que si peu d'équipes sont vraiment encore équipées là-dessus, il y a encore tellement de trucs à faire sur ces sujets-là. que vous avez du taf. Cool. Merci beaucoup, Thomas.
- Speaker #0
Super intéressant. Merci à toi. Merci pour l'invitation.
- Speaker #1
Et puis, au plaisir.
- Speaker #0
De même. Passez une bonne journée. Allez, à tous.
