Transcription

• Speaker #0

  Bonjour et bienvenue dans Nom d'un Pipeline, le podcast destiné à tous ceux qui sont passionnés par le monde du développement, du CICB et du DevOps. A chaque épisode, nous allons plonger au cœur des mécanismes et subtilités des processus de développement qui façonnent notre quotidien technique. Nous allons décrypter, partager et explorer tout ce qui a trait à l'intégration et à la livraison continue. Je suis Julien Donjou, CEO de Mergify, et avec des invités experts, des visionnaires et des professionnels du terrain, je serai votre guide dans cette aventure. Que vous soyez un spécialiste cherchant à approfondir ses connaissances ou simplement que de comprendre les coulisses de ce monde fascinant, vous êtes au bon endroit. Alors, mettez votre série en pause, assurez-vous de ne pas être en plein déploiement et préparez-vous pour ce nouvel épisode de Nom d'un Pipeline. Bonjour et bienvenue à tous dans un nouvel épisode de Nom d'un Pipeline et je suis aujourd'hui avec Guilhem Charles. Salut Guilhem !

• Speaker #1

  Salut !

• Speaker #0

  Alors, peut-être que tu peux commencer par te présenter. C'est un peu la coutume de ce podcast maintenant. Les gens commencent par se présenter, savoir un petit peu qui tu es, d'où tu viens, ce que tu as fait dans la vie, ce que tu fais maintenant.

• Speaker #1

  Oui, pas de problème. Je suis Guilhem, je suis ingénieur logiciel de formation. Je suis originaire du sud de la France. Je fais mes études à Grenoble et après, je suis parti vivre à l'étranger, aux Pays-Bas. Et au niveau professionnel, j'ai l'habitude de résumer ça en… J'ai remonté les différents niveaux de la couche logiciel puisque j'ai commencé à faire de l'embarqué donc plutôt des microcontrôleurs et des linux embarqués etc après je suis passé au niveau applicatif pour applications de bureau puis après serveur on-premise et puis après du cloud avec du python et maintenant du cloud avec du go kubernetes voilà très varié mais le fil plus ou moins c'est voilà c'est de partir d'en bas et de remonter tout en haut

• Speaker #0

  Ok, effectivement parce que l'embarquer, c'est clair que tu es loin de faire du Kubernetes sur l'embarquer, ça n'existe pas encore je crois. Et donc, pour ceux qui ne voient pas la vidéo, qui écouteront l'audio, tu as un très beau t-shirt Datadog, puisque c'est là où tu travailles en ce moment.

• Speaker #1

  Exactement, et en ce moment je travaille à Datadog, donc du coup dans une des équipes qui s'occupe de la CI.

• Speaker #0

  Ok, et peut-être tu peux nous dire ce que tu fais aujourd'hui dans cette équipe. Comment c'est organisé ? C'est quoi ton équipe déjà ? Il y en a combien ? Je ne connais rien de toute cette équipe.

• Speaker #1

  Oui, pas de problème. Du coup, on est dans l'organisation qui s'appelle Developer Experience, qui comprend, ça change parce que ça évolue pas mal, mais on va dire aux alentours de 50 personnes. Dans les équipes qui s'occupent CI, après on a un peu réparti, ça a un peu évolué puisque la boîte a pas mal grandi et le système de CI aussi. Il fut un temps où on était une seule équipe à s'occuper de la plateforme CI, puis après récemment on a divisé ça en deux. Moi je travaille dans la partie qui s'occupe plus de l'exécution, donc tout ce qui va faire générer l'environnement dans lequel le job de l'utilisateur va tourner. Et on a une autre équipe qui s'occupe un peu plus de la partie comment les pipelines vont être générés, comment on va avoir le code, etc. Donc voilà. La particularité de notre CI, c'est que la plus grosse partie tourne sur Kubernetes. Donc en fait, l'idée, c'est comment on va scaler ça, comment on va fournir tous les outils dont les utilisateurs ont besoin, puisque c'est quand même un environnement assez contraint et particulier. Et après, bien sûr, il va falloir s'occuper aussi de ceux qui ont des use cases qui sortent un peu de ça. Par exemple, l'écosystème Mac pour faire des applications iOS ou autres, on ne va pas faire tourner ça sur Kubernetes. Donc il va falloir... leur fournir les environnements dont ils ont besoin, etc.

• Speaker #0

  Ok. Je pense, juste pour le contexte, que je vais me remémorer les derniers épisodes que j'ai pu enregistrer et qu'on a publiés sur la chaîne, mais je pense que tu es probablement une des plus grosses équipes techniques des gens que j'ai interrogés, parce qu'en fait, t'as ta dogme, si toi tu es francophone, en tout cas. Français, j'allais dire, même, peut-être. Mais du coup, je veux dire, la plupart des boîtes qu'on a interrogées ces derniers temps, dans le cas, c'est souvent des startups ou scale-up françaises, mais d'une taille beaucoup plus petite. Et je pense qu'en thème d'ingénierie, moi je le sais un peu, parce que j'ai un peu travaillé chez la tech il y a quelques années, mais aujourd'hui d'ailleurs, il y a combien d'ingénieurs que vous supportez avec cette équipe DevEx, en fait, Developer Experience, voir si il y a, c'est quoi la fourchette à peu près ?

• Speaker #1

  C'est quelques milliers d'ingénieurs. Voilà. Et je pense que le pattern plus ou moins classique, en fait, c'est que les équipes de build restent assez petites, assez longtemps. Parce que je pense que les entreprises ont tendance à les sous-financer, entre guillemets. Et je pense que Datadog a fait réaliser ça il n'y a pas si longtemps que ça. Et donc maintenant, on a beaucoup plus de gens qui ont été embauchés ou qui ont été mis à travailler sur SCI. Parce que c'est toujours un peu un équilibre entre des ingénieurs produits qui passent un peu leur temps pour améliorer la CI, mais ce n'est pas leur job full-time. Et des gens qui passent vraiment 40 heures par semaine dessus.

• Speaker #0

  Je pense à un épisode que j'ai enregistré il n'y a pas très longtemps et qui a été publié au moment où on publiera celui-là avec toi. C'est celui avec Alan du coup. Et effectivement, ils ont une équipe qui est transverse. On discutait avec Tim de ça et l'équipe... transverse fait aussi bien le design system que le CI. Donc, tu imagines, le nombre d'ingénieurs est beaucoup plus petit comparé à l'analogue, donc forcément, ça a plus de sens. Et c'est aussi pour ça que je trouve ça intéressant, je crois, de parler des aspects plus organisationnels et ce que j'appelle social, au sens où comment les gens interagissent entre eux, etc. Parce qu'en fait, l'organisation est souvent très différente quand tu as 50, 100, 200 ingénieurs à supporter, que quand tu en as plusieurs milliers. Je te posais la question, c'est juste pour avoir un souci d'échelle, parce que effectivement, je pense que la taille, tu as forcément 50 personnes dans ton équipe de développeurs. parce qu'elles ont tellement un impact important sur le quotidien de centaines, voire de milliers de développeurs derrière, que c'est un truc assez énorme. Et ça aussi explique pourquoi, je te posais la question, c'est que tu commençais à parler de Kubernetes pour faire tourner un CI, etc. Ce qui n'est pas le besoin et le quotidien de beaucoup d'équipes tech, en général, qui ont des systèmes plus tiens.

• Speaker #1

  Beaucoup de gens qui ont un cube. Et rarement, la première chose qu'on va pour le CI.

• Speaker #0

  Tu ne commences pas par ça. C'est juste pour contextualiser un peu tout ça. Là, on est sur un CI un peu costaud, du coup.

• Speaker #1

  avec une équipe super dédié de grosses tailles etc il ya ce qu'il faut voilà c'est un run complet de faire tomber le cia il va pas rentir non mais je pense que la taille d'entreprise grossi et il va avoir les besoins de déchets bien sûr c'est une première chose mais après va avoir aussi la sécurité la compliance etc qui va devenir de plus en plus compliqué et là tu il faut forcément des gens spécialisés qui posent dessus on aura sans doute l'occasion d'y revenir mais on peut pas garder une équipe de de CI à 5 personnes pour des milliers d'ingénieurs,

• Speaker #0

  ça ne marche pas. Je me pose la question, est-ce que tu as quelqu'un qui gère le côté produit de ce truc-là en fait en interne, ou c'est vraiment que tech-tech, ou tu as carrément un chef de produit CI interne à ce stade-là, ou pas encore ?

• Speaker #1

  Alors on a ce qu'on appelle un IPO, Internal Product Owner, qui m'a l'air d'être un rôle assez récent, je ne vais pas rencontrer ça avant d'aller chez Datadog, mais je n'ai pas bossé dans des grosses boîtes non plus, donc c'est peut-être quelque chose spécifique aux grosses boîtes. Mais donc on a quelqu'un qui va jouer le rôle du Product Owner, sauf qu'au lieu d'aller parler à des gens externes à la boîte, il parle aux ingénieurs principalement. Et voilà, il essaie un peu d'organiser ça en fonction des différents stacks qu'on a dans la boîte.

• Speaker #0

  Oui, mais ça me paraît être un bon truc, parce que si tu ne mets que des ingénieurs ensemble, bon après, ils savent. Quand tu construis un CI, tu construis un système pour des gens qui sont comme toi, donc l'utilisateur, c'est toi. Tu connais le persona et c'est assez facile. paraître assez facile etc même si t'es pas sûr de comprendre tous les besoins parce que tu fais pas le build de l'application iphone par exemple c'est pas toi donc tu peux être pas expert il y a des problèmes etc voilà mais mais avoir ouais je pense que ce road d'ipo ouais c'est une super idée ça me paraît assez potentiellement nécessaire quand t'as une certaine taille d'archébâtre à partir de combien comme tu dis c'est souvent un problème de sûrement un problème de grosses boîtes plus que de petites start up mais ça me paraît pas déconnant sur ce et peut-être d'un point de vue plus technique On a parlé un peu du côté organisationnel. Vous avez quoi ? Un CI pour tout le monde. Tu as plein de petits CI. Tu as commencé à se découper. Parce que j'imagine que la stack doit être assez grosse. Ce n'est pas juste... On fait du GitHub Action et c'est fini. Il y a sûrement un truc un peu plus compliqué parce que les besoins sont plus complexes. Tu commençais déjà à parler de Mac, par exemple. Parce qu'effectivement, il y a sûrement une application. J'imagine une application iPhone. Il y en a une d'ailleurs, je le sais. Pourquoi je dis j'imagine ? Il y en a une, mais forcément. l'application iPhone et il y a peut-être de trucs que je ne connais pas que vous buildez sur Mac ou sur...

• Speaker #1

  L'agent tout simplement. On a des clients qui préfèrent tourner l'agent sur leur...

• Speaker #0

  C'est vrai, moniteurrer vos Mac de prod c'est important, ça que vous avez raté pendant des années sans peur. Pourquoi pas ? Il faut bien builder des trucs à un moment sur Mac donc il faut bien avoir des Mac qui tournent. Ok ouais, et du coup ça ressemble à quoi techniquement ? Tu parlais de cube, c'est quoi un peu la stack typique de vos rivaux ?

• Speaker #1

  Il y a la stack typique que je vais décrire et après du coup il y aura forcément les cas un peu spéciaux que tu... comme tu en as parlé qu'on peut pas rentrer dans le cas typique. Mais le cas typique, un ingénieur va commit son code sur GitHub, c'est là où on a notre code. Ce code va être répliqué dans un GitLab qu'on fait tourner nous-mêmes, chez Datadog, et ce GitLab on va juste utiliser la plateforme CI, donc les fonctionnalités CI, on va pas utiliser tout ce qui est merge request, sécurité, package registry, etc. Non, on a d'autres systèmes pour ça. donc l'ingénieur va pêche son code et il va tourner sur gitlab donc le fonctionnement de gitlab c'est bon bah on a les plateformes gitlab après on va enregistrer des runners qui vont faire tourner les jobs et ces runners donc on va avoir différentes qui vont essayer de satisfaire tous les use cases qu'on a. Le cas spécifique, c'est dans un container Linux, ça tourne sur Kubernetes. Après, en général, ça va couvrir 95% au bas mot des cas d'utilisation. Il va falloir compiler du code, le tester, générer les artefacts, etc. Après, il y a des cas où il faut aller en dehors de Kubernetes. Ça va être par exemple supporter macOS. supporter windows il ya des cas aussi qui vont être assez spéciaux qui rentre pas forcément de manière native dans kubernetes je pense par exemple construire des containers puisqu'en fait tout ce qui est déjà avoir un docker des montres dans un container sur kubernetes niveau sécurité c'est non donc après voilà comment va faire donc après il ya par exemple pour le but des containers image on va faire un but qui a pas besoin d'un docker des montres Après, il y a des produits, par exemple, des gens qui vont tester sur Kubernetes, ça parlera à certains, ils utilisent Kind, donc Kubernetes in Docker, ou peut-être quelque chose de plus mainstream, Test Containers, qui sont des frameworks qui peuvent être utiles. Là, il va falloir qu'on trouve quelque chose d'autre. Donc soit on va démarrer une box sur EC2 qui va être un runner GitLab qui va faire tourner ça, soit on va trouver des micro-VM ou autre dans Kubernetes. On va essayer de trouver quelque chose pour satisfaire ce besoin. Et après, il y a d'autres... Après, il y a les autres use cases, les cas d'utilisation qu'on couvre aujourd'hui, mais qu'on aimerait bien déléguer à une équipe dédiée de tests, tout ce qui va être benchmark, integration test, etc. Les gens ont tendance à mettre ça dans le CI, puisque c'est la place la plus naturelle quand on commence. Mais en fait, plus la boîte grossit, on ne peut pas avoir un benchmark qui va tourner sur un CI qui utilise Kube, puisqu'on va avoir du bruit terrible. sur ces benchmarks donc il leur faut leur propre box ou propre serveur isolé pour qu'ils puissent faire tourner leur truc correctement donc il ya toute une liste de cas comme ça où il va falloir que nous on a cherché un peu plus loin et soit on va trouver un accord avec une équipe pour avoir une sorte d'honneur chez partagé soit on va leur dire bah c'est pas supporter xyz raison ou soit on va demander à une autre équipe de s'en occuper ok potentiellement nouvelle équipe ok voilà ce n'est pas intéressant c'est un sujet que j'ai

• Speaker #0

  que j'avais eu à faire à l'époque où je travaillais chez Latadog pour Transparent et c'était des prémices il y a quelques années de ce genre de problématiques et justement l'un des premiers problèmes qui arrivaient c'était de savoir si ça allait tomber sur du cube ou sur du matos dédié, ce qui était ma recours à l'époque pour faire des benchmarks réplicables c'est pas compliqué de mettre ça sur du cloud ou sur du cube et où tu sais pas que ça tourne t'as des problèmes de noisy neighbors, t'as plein de problèmes Déjà sur du hardware dédié c'est compliqué parce que tu peux te retrouver avec des problèmes à la con du genre le CPU a décidé qu'il n'aurait pas la même vitesse à ce moment-là parce qu'il faisait trop chaud ou je ne sais pas quoi. Donc tu dois avoir des problèmes assez stupides comme ça mais qui impactent tes résultats et qui t'empêchent de bosser de manière convenable sur est-ce que ça va plus vite ou pas. Donc ça c'est un vrai sujet sur les perfs, etc. Et je comprends que tu veux le sortir du série parce que c'est vrai que c'est un... qui a l'air de ressembler à du CI, mais qui en fait, c'est un problème à part entière qui n'est pas 100% parallèle. Oui, ça fait partie de la même workflow, peut-être du même moment où tu dis, il n'y a pas de bug et qu'il n'y a pas de régression en termes de performance qui peuvent être aussi assimilées à un bug. On voit de plus en plus de gens d'ailleurs dans les produits assimiler la vitesse à une fonctionnalité finalement. Peut-être que ce soit rapide, c'est aussi une feature du produit. Donc ça, c'est cool. Donc ça fait partie de ça et pour le tester, ce n'est pas juste d'écrire des tests unitaires ou fonctionnels, c'est d'avoir des sortes de benchmarks, c'est très compliqué de craquer ça.

• Speaker #1

  Je pense que même qu'il y a une autre dimension qui va être la vitesse, parce qu'en fait tes benchmarks, souvent ils vont mettre du temps à tourner, ce qui est normal parce qu'il faut faire plusieurs runs pour avoir une bonne distribution et essayer d'enlever les autres layers. Et si tu mets ça dans le critical path du CI pour merge, en fait tu ralentis pas mal de monde, ou en tout cas tous ceux qui travaillent sur l'application qui vont être concernés par le benchmark.

• Speaker #0

  Je pense que ce n'est pas encore un problème qui est bien résolu et sur lequel il y a encore beaucoup de taf, j'ai l'impression, de manière générale, autour des perfs et du CI, parce que c'est un sujet qui revient assez souvent. On a aussi fait un épisode avec Mathieu il y a quelques mois là-dessus, sur le côté perf et les plans de test pour tester les perfs et compagnie par rapport au CI, et ce n'est pas évident. C'est un peu encore du cas par cas pour beaucoup d'équipes, et puis en fait, c'est difficile de l'industrialiser. Aujourd'hui, il y a quand même beaucoup de gens qui... qui essayent d'avoir cette approche un peu systématique comme le CI, mais c'est très dur, et aussi parce que le problème de fond, c'est que les tests, c'est assez facile de reproduire des problèmes que tu as en production, en disant le cas qui ne marche pas, c'est celui-là, je vais le réécrire dans un test, ça ne marche pas. je le vois, je le corrige, mais pour les performances, il y a tellement de problèmes qui peuvent être liés aux jeux de données que tu auras en production, au trafic que tu auras dans la vraie vie, etc., qui sont très difficiles, pour ne pas dire impossibles, à reproduire dans des jeux de test, ou alors hyper coûteux, que c'est quand même très difficile d'arriver à un système de performance en CIR, où tu es 100% content de ce que tu fais. Oui,

• Speaker #1

  tout à fait.

• Speaker #0

  ça c'est assez dur donc ok donc quoi le système de 6 à 6 10 après à base de cubes et c'est assez générique dans ce que tu décris en tout cas il était quelques je vois quelques petites routes où tu peux t'égarer en faisant des choses un peu custom parce que il ya forcément des choses un peu technique voilà ça d'être une fois qu'il fait un produit technique on n'est pas sur une boîte qui fait un sas pour la santé ou autres où c'est forcément plus du web classique là tu es sur un truc un peu plus technique où tu vas faire des agents qui vont tourner sur des machines effectivement peut-être des docker in docker ou une cube etc tu as besoin de faire un petit peu plus avancé techniquement ça je peux comprendre que tu prennes un peu des chemins détournés qui aussi je pense justifie du coup l'existence d'équipe comme la tienne parce que tu as besoin d'avoir un peu plus de connaissances de savoir et de gérer tous ces cas là pas

• Speaker #1

  laisser les équipes même leur équipe parce qu'on a l'idée de data doc c'est qu'il ya plus ou moins je veux dire un burger quoi donc on a les équipes qui sont vraiment tout en bas qui vont gérer l'interface avec les codes provider et ceux qui vont faire tourner Kubernetes là-dessus. Donc eux, c'est vraiment ceux qui vont s'occuper de nous fournir un cluster kube qui tourne, qui scale. Après, nous, on va se positionner au-dessus, en fait. Et nous, notre expertise, ça va être de faire tourner le CI sur kube ou sur d'autres éléments du cloud provider, donc par exemple des instances OC2. Et après, au-dessus, en fait, on va avoir les ingénieurs qui, eux, vont utiliser la fonctionnalité normale de GitLab CI, donc écrire leur pipeline. Et nous, on va leur donner quelques guidelines, par exemple. Pour faire tourner un job, il va vous falloir un container. On va mettre certaines restrictions sur ces images, puisqu'on a des contraintes de sécurité, etc. Donc, on ne veut pas non plus... Vous n'avez pas... Je ne sais pas quelle image d'Internet et faire tourner ça. Du coup, on va leur dire ça, à préparer au niveau de résolution d'indépendance. On ne va pas laisser nos CI jobs taper énormément dans les miroirs publics. par exemple PyPy ou autre, parce que déjà c'est pas très sympa pour l'infrastructure et ensuite pour nous c'est pas forcément en lien avec ce qu'on veut faire niveau sécurité compliance. Donc du coup voilà, il va y avoir quand même quelques petites restrictions mais l'idée c'est que les ingénieurs aient pas à se soucier en fait de savoir que ça tourne sur Kubernetes ou qu'il va y avoir tel mécanisme d'authentification, d'authentication etc. L'idée c'est de leur dire voilà vous utilisez les fonctionnalités normales du GitLab. il y a ces restrictions sur ces images, si vous voulez avoir un secret dans votre CI, la méthode à prouver c'est celle-là. Et après bien sûr ils peuvent toujours nous contacter quand ils veulent faire quelque chose qui sort de ces rails qu'on essaie de mettre.

• Speaker #0

  Ok, c'est cool. Et donc du coup c'est eux qui sont en charge, tu parlais de GitLab CI, d'écrire après leur pipeline, etc. De faire leur CI à eux, ils ont la plateforme jusqu'au niveau de GitLab et après ils font ce qu'ils veulent derrière, c'est ça ?

• Speaker #1

  alors plus ou moins ça dépend des talibans des équipes en fait et de sur quelle ripo il travaille fait on a une blague en interne qui dit qu'on aime tellement les monopoles qu'on en a plusieurs qu'en fait selon lequel monori pour on est dedans va y avoir des monopoles en fait le ciel va être managé complètement par certaines équipes donc elle pense par exemple l'équipe qui fait du front-end je crois qu'il ya même un blog sur data doc sur ça Là il va vraiment y avoir une équipe dédiée d'ingénieurs qui d'ailleurs sont des experts dans les toolings qui sont utilisés pour le frontend, qui vont s'occuper du CI eux-mêmes. Donc ils vont faire les jobs etc. Et les ingénieurs ils ont juste à coder leurs composants, je ne suis pas expert frontend, ils vont coder leurs composants pour l'UI etc. Et en fait après le CI va se trigger tout seul. Et après il y a d'autres repos en fait, donc soit des monorepos qui ne sont pas managés forcément par une seule équipe, ou des gens qui sont dans des petits repos. parce que, par exemple, ils n'ont pas le choix. Par exemple, les projets qu'on a open source, ils ne peuvent pas vivre dans nos monoripos. Par exemple, je pense l'agent, qui peut plus ou moins être considéré comme un monoripo. Et là, du coup, c'est aux ingénieurs, par exemple, qui travaillent sur l'agent, qui vont écrire le CI et le faire tourner. Donc, il y a deux mondes qui coexistent.

• Speaker #0

  Ok, c'est intéressant. Du coup, tu as deux aspects différents. Et on parlait de GitLab, d'ailleurs, peut-être la question qui se pose aussi, peut-être as-tu la réponse, mais pourquoi ? GitLab CI, sachant que tu sais, tout est sur GitHub. C'est, je pense, la première fois d'ailleurs que je parle avec une équipe où il y a un mix de GitHub et GitLab. Du coup, ça fonctionne bien. GitHub, GitLab CI, a priori, c'est faisable, mais pourquoi ?

• Speaker #1

  Alors, pourquoi la raison date d'avant moi ? Donc voilà, j'ai eu des histoires, des rumeurs. Je ne vais pas trop le dire ce que j'ai entendu, puisque je ne peux pas être sûr que ça soit en passé. Mais en fait, avant, je crois que le setup initial, c'était GitHub Jenkins. Et puis à un moment, il y a eu une décision qui a été faite de se débarrasser de Jenkins. Ils ont évalué plusieurs solutions. Ils ont choisi GitLab CI, sachant que la difficulté là allait être de devoir répliquer le code depuis GitHub jusqu'à GitLab. Donc du coup, voilà. C'est la raison principale.

• Speaker #0

  C'est historique, c'est pas un truc que vous détenez à l'année dernière ? Non, non, non.

• Speaker #1

  C'était d'avant mon temps et même d'avant l'existence de mon équipe.

• Speaker #0

  C'était d'avant mon temps aussi et j'y étais il y a très longtemps. Et je pense, pour apporter ma pierre à cette explication de l'époque où j'étais, c'est déjà du GitHub CI. Et je pense aussi qu'une des raisons, c'est ce que tu disais, Jenkins, etc. Et pour remettre en contexte, à l'époque GitHub Action n'existait pas.

• Speaker #1

  Oui, il n'y avait pas de GitHub Action, il n'y avait pas de Bulk Hides, il n'y avait pas de CircleCI, pas grand chose à cette époque là.

• Speaker #0

  Je pense qu'il y avait CircleCI peut-être quand même, parce que c'est le vieux CircleCI, donc je pense que c'était... Mais c'était peut-être pas la bonne solution comparé à du GitHub CI, je ne sais pas les trucs techniques qui ont été faits à l'époque.

• Speaker #1

  C'est possible.

• Speaker #0

  Et voilà, mais ouais effectivement, donc je pense que c'est aussi un peu un truc, mais du coup ça reste du GitHub CI, il n'y a pas de projet de changement, tout le monde est content de ce GitHub CI.

• Speaker #1

  Alors c'est en discussion... Ok. Datadog est plus ou moins au point critique ou la charge qu'on fait tourner sur le CI. C'est un peu GitLab dans les retranchements. Et ce n'est pas des limitations intrinsèques à GitLab. D'ailleurs, déjà, par exemple, on a fait un fork du runner en interne, passé autour de certaines limitations. On a des patches sur GitLab, la plateforme elle-même. pas forcément très à l'aise avec ça parce que le problème des patchs en fait c'est à chaque fois qu'il faut mettre à jour tu dois te retaper la compatibilité avec les patchs que tu as écrit avant voir s'ils sont toujours valides ou voir si tu peux les porter facilement ou pas donc c'est un peu du travail répétitif en plus pour les ingénieurs.

• Speaker #0

  Il n'y a pas moyen de les envoyer upstream pour vous ou c'est des trucs trop spécifiques ?

• Speaker #1

  Alors il y a des trucs qui sont assez spécifiques des fois on reporte des issues upstream des fois on suit un peu les évolutions de GitLab à faire. Le problème c'est qu'on n'est pas un client de GitLab, donc on n'a pas trop de pouvoir politique pour pousser certaines issues sur leur tracker pour dire il faut donner la priorité à cette fonctionnalité ou ce changement. Donc ce n'est pas toujours évident. Donc voilà, on est en train de réfléchir, est-ce qu'on continue avec GitLab ? Est-ce qu'on fait un mix GitLab, quelque chose d'interne ou est-ce qu'on construit quelque chose d'interne ?

• Speaker #0

  Ouais, je comprends. À cette échelle-là, je pense qu'effectivement, tu as des problèmes de scalabilité sur GitLab que peu de gens ont, etc. Quand tu arrives à ce genre de taille, n'importe quel outil au-delà de GitLab, on peut assez vite se retrouver avec des problèmes parce que c'est un niveau d'échelle que peu de gens atteignent, peu de boîtes atteignent, peu d'équipes atteignent. Donc forcément, je pense que c'est plus compliqué et que ce n'est pas très étonnant autant que tel. Non, mais c'est intéressant d'avoir un peu l'historique et peut-être même le... un petit aperçu du futur potentiel ou possible, si jamais ça change. Donc ça reste à étudier. Mais je comprends que ça peut très bien finir en système custom, parce que les besoins sont tellement déterminés, spécifiques, et que vous avez la capacité d'eux. Avec ce nombre de développeurs, tu peux prendre quelques développeurs et les jeter sur le problème pour le résoudre en quelques mois, etc. Tu as les moyens d'eux, donc ça peut être un truc assez... Ce n'est pas le cas de tout le monde. Non, c'est bien. C'est le problème de Rich.

• Speaker #1

  C'est le problème de Lux, exactement.

• Speaker #0

  donc ok c'est cool c'est intéressant et tu parlais de sécurité c'est un truc qui m'intéresse pas mal comment vous gérez cette sécurité tu parlais de contraintes mais concrètement est-ce que c'est un truc que vous arrivez à enforcer à bloquer est-ce que c'est très juste des guidelines est-ce que vous avez des trucs là-dessus et c'est quoi les enjeux en termes de sécurité c'est pas un sujet dont on parle souvent parce que c'est pas un sujet je pense qui est très vu dans le CI aujourd'hui même si ça l'est de plus en plus mais c'est encore un peu un un angle mort parfois je pense pour certaines équipes on ne regarde pas trop ce qui se passe alors que ça peut être un vrai problème et comment vous gérez ça dans votre équipe ?

• Speaker #1

  Alors il y a plusieurs aspects, donc déjà il y a Datadog qui a sa propre équipe enfin organisation de sécurité qui est en charge de superviser tout ce qui se passe à Datadog, CI ou autre donc déjà eux ils ont aussi leur rôle à jouer dans le sens recommandation je ne sais pas vous avez les... utiliser cet algorithme d'encryption ou là il y a ce package qui a une vulnérabilité etc d'ailleurs je crois qu'il y a Datadog qui a des produits de sécurité donc on va aussi utiliser tout ce qui est disponible sur la plateforme Datadog Ensuite, il y a le rôle qu'on a à jouer nous au sein du CI. Et le CI, c'est un peu... En fait, comme c'est la porte d'entrée de tout ce qui va arriver en production, c'est aussi un peu là où on a tendance à mettre toutes les vérifications dont on veut être sûr que ce qui finit en prod respecte. Et par exemple, quelque chose à laquelle je pense, c'est le fait qu'on parlait de construire des images de containers. tout à l'heure en fait un des droits et menthe qu'on a pour arriver en prod c'est de ne pas avoir une image de base qui soit trop vieille donc fait on veut que l'image soit jour sur tout ce qui va être patch de sécurité ou version de package system ou autre etc donc là en fait dans le cia et on va avoir un check qui va détecter si ça c'est bien ou pas est ce qu'il ya des failles de sécurité connus qui font partie de ce ce container etc et le fait de l'avoir en 6e en fait ça évite que ça arrive en prod et il ya même en fait même si tu arrives en fait c'est check faut être bloquant pour la prod donc donc elle pourra pas déployer en prod une image qui n'a pas été vérifiée par le ciel et donc là aussi il a pour une équipe comme la mienne va y avoir des challenges puisque ça va être ok comment on est sûr que personne puisse faire un manifeste frauduleux qui disent qu'il a passé les tests alors qu'il les a pas passé comment on est sûr que le manifeste il correspond bien au code source qui a été build etc etc etc donc voilà il ya plus ou moins ces deux aspects et après il y a tout ce qui va être enfin par exemple il ya des évolutions aussi puisque à la fois l'équipe de CI et l'équipe de sécurité grandissent comme la boîte grandit il y a de plus en plus de monde donc on peut s'occuper de plus de sujets un sujet qui est venu récemment par exemple c'était l'utilisation de secrets dans la CI Nous, on avait mis des recommandations sur ce qui nous semblait bien à l'époque. Les systèmes ont évolué et du coup, sécurité, à un moment, est venue nous dire, en disant, en fait, il y a des meilleures pratiques que celles-là. Donc, ils ont mis à jour les recommandations pour la secré. Et en même temps, on a transféré aussi l'ownership de la gestion des secrets en CI à l'équipe sécurité, puisque c'est leur expertise. Donc, du coup, voilà, c'est un peu la relation entre les deux et comment on gère la sécurité.

• Speaker #0

  voilà c'est clairement du point de vue de la cia et un niveau application je pense qu'il ya aussi des tests de sécurité qui sont effectués mais oui ça notre aspect qui est mort de la csa donc je peux pas en parler par contre comment tu cher question question comment tu gères on ne t'a pas vu utiliser voici quelqu'un but d'une image avec le dernier cv ou n'importe quoi pas de sécurité tu l'empêche de partir en prod c'est cool mais c'était l'image qui part en prod et qui après coup se retrouve avec un cv sur l'image en cours est ce que ça aussi de la responsabilité de la partie CI ou du coup tu es plus sur un problème de run entre guillemets et c'est un autre aspect que vous gérez pas vous ?

• Speaker #1

  Non, donc on va pas gérer ça nous ça va être un aspect de run time effectivement, il va y avoir des moniteurs qui vont être triggers en fait du coup sécurité va avoir des moniteurs là dessus, ok on a détecté je sais pas, un secret qui a été commit par exemple dans GitHub bien que bien sûr on a des pre-commit check etc...

• Speaker #0

  Il y a plein d'intensités.

• Speaker #1

  Par exemple, il y a un secret qui a été détecté dans le code, ou il y a un secret qui a été détecté dans les logs, ou il y a une faille de sécurité qui a été détectée dans des containers. Parce qu'en fait, des fois, les failles de sécurité, elles arrivent après que tu aies déployé. Il y a une nouvelle faille de sécurité qui a été trouvée, elle est devenue publique, donc on va avoir Datadog, la plateforme, qui va devenir consciente de ça. Du coup, nouveau check sur les containers, et là, d'un coup, nouvelle faille de sécurité. on a tant de containers qui... On va plutôt regarder ça du niveau application. Donc on va dire, il y a ces services qui appartiennent à ces équipes, et là, on va ping directement les équipes. C'est plus l'aspect runtime, ça sera pas fait dans la CL.

• Speaker #0

  Ça veut dire que ton build est bloqué tant que tu ne corriges pas le problème de sécurité de manière ou d'une autre a priori. Soit tu le corriges, soit tu l'ignores, et ton CL va te bloquer.

• Speaker #1

  C'est souvent le repository dans lequel tu travailles, mais oui, c'est l'idée.

• Speaker #0

  OK. Ouais, ouais, non, ce qui ne me paraît pas non plus déconnant. Si tu prends la sécurité aussi sérieusement, ce que tout le monde devrait faire, bien sûr, ça me paraît assez malin comme système. On installe un peu Connect chez nous, on ne bloque pas, mais on a un scan quotidien des images Docker avec les vulnérabilités, et on est obligé de faire une review des vulnérabilités existantes, soit de les supprimer, des corriger, soit de dire qu'effectivement celles-ci ne nous impactent pas parce que c'est dans une libre image de base qu'on n'utilise pas, ce genre de trucs, des fois des CVE qui sont tellement basses que tu peux les ignorer en disant qu'il n'y a vraiment pas de risque. ça c'est ton process mais du coup on a vraiment ce process un peu alors ça nous bloque pas en tant que tel on n'en est pas je pense à ce niveau là mais on pourrait aussi avoir un niveau comme ça parce que ouais tu veux être sûr que tu es sûr que tu as un truc qui soit d'avoir la liste de tes vulnérabilités de dire ça là je décorais ça là je ne décorais pas et d'être sûr que tu prends tout le temps ça je pense

• Speaker #1

  qu'on a cette proche au niveau du une fois que l'image de container est build ça va apparaître en amont donc en fait on va avoir des veto sur les images qui vont être utilisées comme base donc pour l'application. Comme ça tu sais que tu peux utiliser uniquement celles qui ont été approuvées. Et après, puisqu'il faut quand même installer l'application devant l'image du container, là on va avoir des scans sur les packages.

• Speaker #0

  Ok, donc à un autre niveau.

• Speaker #1

  Exactement, ça va prendre deux temps.

• Speaker #0

  Et du coup, à quel moment tu bloques cette gestion des images en fait, t'as un système particulier ou c'est un truc que vous avez fait vous ?

• Speaker #1

  Ouais alors nous pas mon équipe mais dans l'organisation on a en fait on a un système qui construit des images de base qui sont approuvées et qui vont être mises à jour automatiquement et en fait après on a des mécanismes pour rebuild automatiquement dès qu'il y a une update. Donc ça fait que 1 on est sûr que les gens ne peuvent utiliser que les images de base qu'on a approuvées puisque là il va y avoir un filtre et en fait tu vas être bloqué quand tu vas essayer de déployer ton artefact en prod, prod va regarder. Est-ce que je connais cette image de base et est-ce qu'elle est approuvée ? Oui, je laisse passer, non, je bloque. Et la deuxième, c'est qu'en fait, ce mécanisme, il nous autorise aussi à pouvoir rebuilder les images avec les patches de sécurité, si on sait qu'il y en a qui ont été délivrés, sans avoir une implication des équipes qui font partie de leur service. Donc en fait, on a un système de rebuild et de déploiement automatique pour ce genre de choses, parce qu'a priori, alors bien sûr, après... on va pas rentrer là dedans mais c'est parce que c'est plus la partie cd mais il va avoir tout un mécanisme qui va faire que tu veux détecter si un déploiement et successos ou pas et roll back s'il n'est pas successos mais l'idée c'est qu'en fait tu as ces tests et une confidence qui te permet de dire ok c'est le moment alors je sais pas chaque lundi matin tu vas ribules des images de base celles qui sont approuvées pour avoir les derniers pages de sécurité et après en fait de fil en aiguille tu vas arriver tout en bas jusqu'à aux applications de service qui elles vont être au but sur les dernières versions des librairies ou de l'image et après déployé puisque l'idée c'est que si le code de l'application ne change pas a priori il va y avoir très peu d'occasions mettre

• Speaker #0

  à jour l'image de base avec des patchs de sécurité vont casser l'application ça peut arriver bien sûr mais c'est assez rare et puis tu as aussi besoin de le faire mais si l'action ne change pas tu as besoin de rebondir avec les dernières pages de sécurité même s'il se passe rien exactement plusieurs jours semaines parce que parce que c'est les vacances peut-être ou peut-être juste rien à faire et voilà où l'application legacy et justement tu parlais en question parfaite de déploiement est en fait on n'a pas parlé jusqu'à présent mais est ce que c'est vous qui gérez aussi la partie un peu sidy alors oui c'est du développement continu évidemment on est sur du sas on est sur un truc qui tourne 24 7 et on touche des trucs tout le temps voilà classique comme on peut imaginer sur sur du sas et vous envoyez pas des cd roma vos clients mais du coup comment tu vas Est-ce que c'est vous qui gérez ça d'abord ? Est-ce que c'est chaque équipe qui se débrouille ? Jusqu'où vous allez dans le support du déploiement ? Est-ce que tout le monde fait du déploiement continu ? Ou est-ce qu'il y en a qui ne font pas ça ?

• Speaker #1

  L'idée, c'est que tout le monde fasse du déploiement continu. J'essaie de penser à une équipe qui déploie le CS back-end, qui n'en fait pas, mais il n'y en a aucune qui me vient à l'esprit. Je serais tenté de dire que tout le monde en fait. Mais ce n'est pas nous qui gérons ça. À TataDog, on a vraiment séparé le CI du CD. D'ailleurs, le CD est dans une organisation complètement différente. Ils sont plus proches du runtime. pour des raisons qui font que le déploiement à Datadog est vraiment lié de manière très proche avec la plateforme qui tourne dessus donc il faut quand même une expertise un peu plus avancée pour s'en occuper après il ya quand même des déploiements qui sont trigger à partir du CI quand on merge sur mine ou quand on utilise une branche d'intégration etc et qu'on déploie sur staging il y a plusieurs mécanismes ça peut aller du un commentaire dans la pull request sur github pour dire je vais déployer ça sur l'instant staging de mon équipe merde et puis après ça part en prod mais le système peut être appelé d'un pipeline de CI mais c'est pas nous qui nous occupons du fait nous on trigger juste en disant bon et voilà faut déployer cet artefact qui est identifié par telles informations sur ce cluster ce datacenter peu importe après chaque équipe configure eux-mêmes ce qu'ils veulent faire.

• Speaker #0

  Ok ouais donc c'est vraiment une équipe à part entière qui est comme tu dis c'est plus proche du run etc c'est vraiment pas dans la partie CI c'est vraiment une étape d'après qui est décorrélée de la partie 6e oui tout à fait ok c'est assez assez marrant tu parlais de staging du coup il ya une plateforme de ce que j'imagine que la prod n'est pas toute petite chez la table de développeurs on peut imaginer facilement la taille immense du cloud qui tourne derrière avec des clouds d'ailleurs parce qu'il a plein chez Et du coup c'est quoi la partie staging ? C'est vous aussi qui êtes responsable de ça ? Donc il y a une plateforme de staging j'imagine, où les gens peuvent tester des trucs ?

• Speaker #1

  Alors oui, il y a un environnement staging. Ce n'est pas nous qui nous en occupons, mais l'idée c'est ça en fait, c'est que les gens déploient sur staging, puis après ils font leurs tests, soit d'intégration, soit autre, et après ils passent en prod.

• Speaker #0

  Ok. Voilà. Mais c'est 100% du coup c'est pas du tout lié au CI en fait, c'est vraiment un environnement à part entière qui n'a rien à voir avec...

• Speaker #1

  Ça dépend, donc là en fait les ingénieurs ont plus ou moins la liberté de faire le flow entre guillemets qu'ils souhaitent. Il y en a qui utilisent des branches d'intégration par exemple, donc ils vont déployer, ils vont avoir un environnement où il y a juste des changements qui concernent leurs services qui vont être déployés. Et après leurs services... quand ils doivent parler des services externes dans leur équipe, ils vont soit parler à la prod directement, enfin, une instance de prod dédiée pour nous, soit à un autre environnement staging. Après, il y en a qui déploient juste dans staging quand ils mergent à mine. D'autres qui déploient dans staging automatiquement quand ils pushent sur une branche. Ça dépend vraiment de ce qu'ils ont setup eux-mêmes.

• Speaker #0

  ok du coup vous laissez vraiment la liberté là dessus c'est ça qui est assez marrant c'est finalement vous êtes assez nombreux et une équipe des essais mais en fait finalement il ya beaucoup de ya vraiment un petit on tient un petit aspect de ce que vous fournissez mais le reste est quand même assez libre pour les développeurs de s'arranger un peu comme ils veulent et comme tu disais vous avez plusieurs monoripos finalement papa un seul monoripo vous gérez tout de a à z et tout est défini en fait de ce que je comprends c'est vraiment chaque équipe a plus ou moins un plusieurs ripo monoripo etc et après un framework de base avec des contraintes de sécurité, de best practice, etc. Mais peut quand même pas mal s'adapter. Ce qui est plutôt une bonne chose, je pense que ça permet d'avoir de la liberté pour les développeurs qui savent mieux que vous sûrement ce qu'elles sont leurs contraintes, leurs prérequis, etc. Mais ils ont une grosse brique de base avec Kube, GitLab, etc. pour vraiment construire ce qu'ils ont besoin. Mais ça ne va pas jusqu'au déploiement. Staging aussi, c'est dans leur scope. Donc c'est assez limité finalement votre scope, même s'il est très gros vu la taille de l'organisation. mais non ça suffit ouais.

• Speaker #1

  Ouais alors après c'est vraiment la culture Datadog de dire en fait on a pas de mandat exactif pour dire vous allez faire ça. En fait on peut faire des carottes mais on a pas le droit d'utiliser le bâton. Donc voilà, si on veut convertir des utilisateurs à un nouveau système ou un nouveau mécanisme qui nous facilite la vie ou qui est mieux pour la boîte, c'est à nous d'aller convaincre les gens. après là on va avoir un mandat bien sûr c'est ok bon bah il faut qu'on soit compétent sur ces aspects la seule manière de le faire c'est de cette manière là et là du coup là tout le monde est obligé de de passer puisque en fait c'est un objectif de l'entreprise et plus non plus seulement de notre équipe logique

• Speaker #0

  quoi est ce qu'il ya des gros projets que tu as fait depuis qu'il est arrivé c'est quoi deux ans maintenant chez la tag est ce qu'il ya des tu as des milestones dont tu es super fier par toi ou ton équipe ces derniers mois, années. Tu parlais par exemple des secrets, c'est un peu assez intéressant. Je pense qu'il y a d'autres aspects comme ça que tu as vus depuis au moins deux ans, ou peut-être commencer avant que tu n'y arrives, mais de projets, de migrations, de changements, d'améliorations notables que tu peux partager.

• Speaker #1

  Oui, je pense que ce qui me vient à l'esprit, sur lequel j'ai sûrement travaillé le plus, c'est justement, je parlais des macOS tout à l'heure, c'était de fournir un CI pour macOS aux ingénieurs qui font du macOS à Datadog, ce qui n'était pas forcément évident, parce qu'Apple, de manière très surprenante, en tout cas pour moi, mais peut-être que pour eux c'est un peu moins surprenant, ils n'ont pas du tout dans l'idée de faciliter la vie de ceux qui veulent faire du Mac en serveur, puisque bien sûr Mac n'est pas un serveur, donc dès qu'on veut faire du CI dessus, ça devient beaucoup plus dur. Donc la solution de facilité c'est d'avoir une armoire de Mac mini qui... qui font tourner ton CI. Mais après... Il y a plusieurs risques, est-ce que ça va faire un incendie ? Avoir ça au bureau, ce n'est pas forcément ce que les gens veulent entendre. Il y a une solution de virtualisation qui existe sur AdBell US, dont on a opté pour. Après, il faut arriver à contourner tous les bâtons qu'Apple te met dans les roues, qui ne sont pas forcément voulus, mais qui sont dûs au fait que ce n'est pas du tout leur use case de faire tourner du CI. Et d'ailleurs pour la petite anecdote, AWS ce qu'ils font c'est qu'ils rackent des Mac Mini dans leur data center. Et la partie barante c'est qu'ils ont un doigt robotique qui peuvent trigger de manière programmatique pour appuyer sur le bouton on and off quand ils veulent reboot les machines. Je pense que ça dit assez le niveau dans lequel on s'embarque quand on va aller faire du CI sur macOS. et après l'autre difficulté en fait c'est que quand on fait du 6e aille et qu'on vient d'un background je parle pas qu'elle par exemple c'est plus ou moins facile entre guillemets quand on s'attaque à l'écosystème mac os en fait trouver des gens qui font du back-end qui s'intéresse aussi à y faire taff style platform et qui connaissent les coups le système mac os donc ils font du swift l'objectif c'est qu'ils connaissent les différents tricks pour xcode ça devient assez dur pas dire impossible il existe mais ils sont pas ils sont pas beaucoup de compétit va avoir vraiment beaucoup de dialogue à faire avec avec les équipes d'ailleurs je salue les équipes et qui j'ai travaillé à datadoc qui était très utile puisqu'ils vont expliquer en fait bon mais voilà xcode si tu veux avoir plusieurs versions qui coexistent faire comment l'attirer et après bien sûr Autre anecdote aussi, Xcode par exemple, on ne peut pas le télécharger de manière programmatique. Si on veut une version d'Xcode, il faut aller se login sur le portail Apple avec des credentials. Après on peut mirrorer le binary en interne et après installer ça, mais c'est toute une suite de challenges comme ça qui fait quand même qu'on est arrivé à bout et c'est quand même assez satisfaisant maintenant d'avoir du CIE en Internet Datadog qui tourne dans le cloud. D'ailleurs les équipes en sont très contentes et après on a même... On a même eu des use cases auxquels on n'a pas pensé avant qui sont ajoutés du style des gens qui veulent précompiler des librairies. Par exemple, tout ce qui est C++ Rust qui met du temps à compiler. En fait, ils veulent des librairies précompilées pour pouvoir télécharger directement sur leur Mac pour accélérer un peu le cycle de développement.

• Speaker #0

  Tu demandes même comment les gens de chez Apple font pour faire du CIE. Est-ce qu'ils font du CIE ? Sûrement. Comment ils se trouvent en interne ?

• Speaker #1

  J'ai trouvé plus ou moins la réponse justement en travaillant sur ce projet. Il y a quelques années, ils ont release un framework de virtualisation natif qui est fait par Apple lui-même. Alors le trick, c'est qu'en tant qu'utilisateur d'Apple, tu es limité à deux machines virtuelles à la fois. C'est une limite qui est hard-codée en interne. Et en fait, il y a des gens qui ont hacké, qui se sont amusés à aller changer ça dans le kernel. Et en fait, si tu le changes à plus, tu peux en faire tourner plus sans problème. À mon avis, en interne, il ne se prive pas d'avoir 50 VM qui tournent sur le même serveur. Après, nous, en tant que simple utilisateur, on est une

• Speaker #0

  CAD. Ok, ça ne résout pas non plus le problème d'avoir des machines Apple avec un doigt robotisé si besoin. Pour la prochaine, tu as quand même ce côté-là où le matériel n'est pas fait pour. pour finalement être hackés et tout, donc ils doivent avoir les mêmes...

• Speaker #1

  Juste pour savoir comment ils font ça en interne, justement.

• Speaker #0

  Ouais, c'est à ce niveau-là, c'est qu'ils ont construit leur propre serveur basé sur ce qui est possible, mais est-ce que du coup... Enfin, je me dis, c'est bête, mais finalement, le devoir d'avoir un CI pour Apple, c'est un besoin. Donc soit Apple fournit une ferme de CI avec un abonnement, et pour tous les développeurs Apple, enfin, de l'écosystème, soit c'est une solution. Parce que là, du coup, il y a une sorte de manque que...

• Speaker #1

  c'est la brique manquante dans le ski est assez étonnant en plus parce que l'écosystème pour ceux qui font de la us par exemple c'est un des meilleurs il ya vraiment tout qui marche assez simplement où les gens enfin toutes les équipes à qui j'ai parlé avait une très bonne expérience classe vrai que la cia et qui manque c'est un peu la brique manquante de l'écosystème apple c'est pas trop après d'expérience rentrer dans le marché tiers général c'est pas il n'y a pas beaucoup de boîtes qui ont réussi là dedans Donc c'est peut-être ça qu'ils veulent éviter. Mais après, est-ce que ça justifie pour autant de limiter ceux qui veulent le faire ? Je ne sais pas.

• Speaker #0

  C'est une bonne question. c'est assez particulier pour le coup on parlera un bon décès avec ça reste une petite partie de effectivement quand tu as une ap mac ou ios et c'est d'arrêter en a besoin ça reste un besoin très précis et c'est tout on n'a pas ces besoins là et où mais c'est vrai c'est un truc qui revient pour toutes ces équipes là et qui paraît pas si gros que ça mais en fait qu'un vrai pain du coup effectivement vous l'avez résolu avec lbs et genre de trucs mais bon on veut sortir des doigts robotique c'est pas ouf comme solution il ya un truc à faire mais bon le matériel à Apple est tellement locked in que ça me paraît compliqué aussi de se passer d'Apple pour résoudre ces problèmes-là. Mais ok, intéressant. Et dans le même genre, est-ce qu'il y a des projets dont tu peux nous parler ces prochains mois, années, que tu vois venir ou des challenges ou des trucs qui commencent à ne plus trop marcher, à falloir regarder ? Tu parlais un peu de GitLab tout à l'heure, mais est-ce qu'il y a d'autres trucs comme ça où tu te dis là, on y va ou en ce moment, sur lesquels tu bosses ?

• Speaker #1

  Non, il y en a plein. L'échelle, c'est toujours le problème récurrent. On patch, on fait des trucs, mais la boîte continue d'embaucher plus d'ingénieurs. On voit que l'utilisation de CI suit une croissance exponentielle qui n'est pas linéaire avec le nombre d'employés, mais ça, ce n'est pas forcément une surprise. Il va falloir continuer à scaler tout ça. Déjà, on a un travail remarquable qui est fait par les équipes qui s'occupent du cloud et de Kubernetes qui nous permettent vraiment de pousser les limites. Après, nous, on essaie de faire ce qu'on peut avec GitLab. Je pense que ça va être un gros sujet des années à venir pour mon équipe. Après, au niveau développeur expérience et CI, il y a plusieurs trucs qui viennent. Il y a des repos, par exemple, qui ont une merge queue qui est enforcée, pour parler de quelque chose qui est lié à ton expérience. Et il y a d'autres repos où on a du mal à enforce cette merge queue pour tout un tas de raisons. Il y a les tests flaky, etc. des gens qui ne veulent pas faire comme ça, etc. Donc là, il va falloir trouver les mécanismes, par exemple des game days, tous les vendredis du mois, on fait tourner le repo sur Mercu, etc. Et l'autre aussi, qui est dû à l'échelle de CI qu'on a, on sait que du côté change detection, on n'a pas une très bonne histoire, historiquement, à Datadog, on a tendance à buller beaucoup trop. Une des raisons, c'est... des ripots qui sont sous basel d'utilisation basel qui pas optimal d'autres ripos il ya d'autres raisons en fait je pense que ça aussi ça va être une grosse pièce du puzzle puisqu'on a des gens en fait qu'ils viennent d'autres d'autres boîtes si google amazon etc qu'on beaucoup plus de développeurs que datadog qui ont pas forcément la même taille de 6 hayes en proportion de cocaïne c'est qu'il va falloir on bulle de trop il va falloir trouver un peu tout ce qui est fait en trop et c'est de le réduire et faciliter notre vie aussi ce serait pas mal sûr ouais donc ouais optimiser le gros sujet et le test benchmarking qu'on a mentionné au début du podcast qui est en train de devenir un sujet en lui-même mais je pense que c'est aussi dans l'industrie ce que justement recherche on a vu pas mal de boîtes qui se lancer sur ça j'ai pas les noms en tête mais ouais

• Speaker #0

  ouais il y en a quelques-unes qui sont un peu là dessus et ouais c'est un sujet qui vient pas parce que je pense que personne n'a vraiment craqué le problème pour l'instant donc il ya plein d'approches diff��rentes lundi des mets à voir ce qui se développera peut-être pas une idée et une solution pour tout le monde mais ok intéressant tout cas je pense que les problèmes de d'utilisation de ressources un problème récurrent que tout le monde a plus ou moins pour longue échéance quand tu crois et qu'il faut toujours avoir un petit côté où tu regardes ce que tu fais pour dire attend mais est ce que ça part pas trop effectivement comme dit c'est croit de manière exponentielle là où tourner le beurre était pas aussi exponentielle mais plus linéaire et c'est problématique mais bon En général, le bon signe, c'est que les gens utilisent le CI pour tester de plus en plus de trucs, etc. Mais c'est vrai qu'après, il faut des fois rationaliser, faire des cuts et se dire, est-ce qu'on teste peut-être un peu trop ? Est-ce qu'on build un peu trop ? Est-ce qu'on peut batcher ? Est-ce qu'on peut faire plein de trucs comme ça derrière ? Ça peut être assez intéressant. En tout cas, c'est une bonne liste de projets de quoi t'occuper. On va être très occupés,

• Speaker #1

  oui.

• Speaker #0

  C'est cool. Autant, c'est ce qu'il faut. Merci. Guilhem, c'était super cool de parler de tout ça, d'apprendre un peu comment ça marche chez Latadog en interne, tout ce côté CI, d'avoir une équipe dédiée, tout ce que vous avez fait en projet, etc. Je te remercie d'avoir partagé tout ça. Et puis, au plaisir.

• Speaker #1

  Ok, merci de l'invitation. C'était un vrai plaisir. Salut. Salut, bonne journée.

• Speaker #0

  Et voilà, c'est la fin de cet épisode. Un grand merci à vous de nous avoir écoutés aujourd'hui dans cette exploration du monde fascinant du DevOps. Si ce podcast vous a plu, n'hésitez pas à le partager, voire à me laisser un avis, voire à me laisser 5 étoiles sur votre plateforme de podcast préférée. Ça m'aiderait énormément et ça fait toujours plaisir. Restez connectés pour encore plus de découvertes, d'astuces, de témoignages inspirants dans les prochains épisodes. Et d'ici là, gardez vos pipelines fluides et votre CI bien adapté. A très bientôt pour une nouvelle aventure au cœur du CI-CV.