 On peut commencer à papoter tranquillement le temps que les gens y arrivent, mais c'était génial de la démo, franchement. Moi, quand je monte du Kennedy ou du Kafka, c'est du Hello World qui active un autre pote qui fait Hello World. Voilà, là, c'était l'activation de Blender, Rendering et tout, mais bon, avec Laurent, je sais, c'est après un fois que je voyais Alain présenter aussi, mais Laurent, il fait toujours des démos qui sortent un peu de l'ordinaire. Alors, je regarde un peu dans le chat, si tout se passe bien, j'attends un petit peu le go de Sun qui va me dire... Alors, tu veux voir, tchac tchac tchac, vous, ça va ? Vous n'avez pas d'orage chez vous ? Moi, pour l'instant, non. Moi, j'ai même presque du ciel bleu, dis donc. Qu'est-ce que du ciel bleu ? Ah ouais, moi, je vais attendre, je vais regarder. Vous ne pouvez pas regarder pas tout. Moi, il fait 27 degrés, il fait là. Donc, voilà, ouais, c'est la rivière. Ok, vous savez quoi, en attendant 2 secondes, je vais juste partager mon écran, on va voir un petit peu où on en est au jeu de la bataille navale. Parce que je crois qu'il y a un gros combat. Dashboard. Alors, vous devez voir mon dashboard là. Alors, ça ne joue plus trop là, je vois. Mais le top 10 se partage entre ces deux personnes. Il y a Glory Ridge, qui est la première et la deuxième place. Et il y a Weed, Weevil, qui a les autres places. Et à eux deux, ils arrivent à se partager le top 10. Donc, le jeu tourne encore. Donc, n'hésitez pas à aller jouer. Là, il y a 23 joueurs encore connectés. Essayez de les battre. Parce que, voilà, ça va être faisable. Je vais vous remettre l'url du jeu. Dans le chat. Dans le chat. Je le mets là. Je le mets dans Event. Voilà. Je vais couper mon... Non, pas tout. J'allais faire stop broadcasting, ça aurait été dommage. Stop sharing, voilà. Ouais, ouais, trop de boutons. Bon, ça va. La plateforme, elle tient, elle n'avait pas trop eu de soucis. Donc, voilà. Bon, écoutez, on va commencer tranquillement. Donc, c'est la table ronde. Quand la CIA est bonne. OK. Donc... Ouais, au passage, bravo pour le teaser. Ouais, ouais. Mais en fait, c'est une vieille... C'est un vieux tweet que j'avais fait. J'avais... J'ai repris celle-là de... de Goldman, mais j'avais fait aussi tout un... tout une compile. Il y a compile au moins. Compile au moins. Compile au moins. Qu'est-ce que j'avais fait encore? Elle met des vieilles textes. Ah oui, elle met des vieilles textes sur son LinkedIn et les signants, les bobos, voilà. Il y a... Bon, il y en a toute une série. C'est génial. Chaque chanson de Jean-Jacques Goldman, je crois qu'on peut en faire un tube IT. Voilà. Et donc, oui, j'ai trop saigné avec Tecton. Ça, là, c'est quelqu'un qui m'avait sorti. Je crois qu'il m'avait sorti ça. Ça fait saigner un peu Tecton et je crois que je venais juste de finir un tout Tecton et je lui sens ça en tête. Et c'était le même moment où on m'avait aussi montré comment faire l'autotune avec garagement sur le Mac. Donc, c'est pas facile à l'autotune parce qu'il faut trouver la bonne note. Donc, moi, je me moque beaucoup de ceux qui ont l'autotune, mais il faudrait même trouver la bonne note et tout. Et après, c'est très rigolo. Donc, du coup, attendez, je regarde s'il sonne, il me fait un petit signe. Ah oui, il y en a un qui dit, après les vieilles charrues, il y a Seb. Moi, je me regarde à chanter. Mais moi, je chante pas très bien, alors qu'il y a Sylvain que vous connaissez peut-être, qui lui a carrément sur son site web, il fait plein de reprises de chansons, genre le Craftman gagnant et tout. Il en a tout une série. Et la semaine prochaine, il vient arriver à Dev pour faire un talk sérieux, mais il a dit, si vous voulez, je peux pousser la chansonite aussi. Donc, il va ramener son micro et à la fin, au moment du cocktail, il va pousser la chansonite sur deux, trois chansons. Donc, ça va bien le faire. Bref, on est là pour parler de C.I. C'est une table ronde. On va discuter. Ce que je propose, c'est qu'on fasse, vu que c'est une table ronde, un tour de table pour se présenter. Je vous laisse vous présenter. Et après, il y a une petite question. Non, on va voir. Lançons le tour de table d'abord. On va commencer en en l'ordre. C'est Philippe. Ok, salut. Merci Sébastien de me recevoir. Moi, je suis Philippe Charière. Je suis technique au Lacanx Manager chez GitLab. Je m'occupe des clients une fois qu'ils sont clients entrepays. Ok. Vincent. Yes, Vincent Domesther. Seigneur principal software engineer à ADAPT. Mais je suis principalement lead du projet Tecton, donc tous les composants de Tecton, à la communauté etc. et la partie intégration de un peu de choses. Ok. Et finalement, Tug. Je suis Tug DualGram. Je suis solution engineer chez GitLab. Depuis 4 mois, donc c'est assez récent. Et en fait, solution engineer c'est que j'aide l'équipe vente à vendre GitLab Enterprise à ses clients. Donc accompagner les clients en avant vente, en post vente et aussi des événements qu'aujourd'hui. Donc avec la communauté de développeurs le plus possible comme j'aime le faire et comme je l'ai beaucoup fait voir le passé. Ok, ok. Cool, cool, cool. Donc, l'idée de se parler de CI CD dans le cloud peut-être rappeler aux gens qui sont tous là peut-être qu'on est dans notre bulle c'est peut-être pas forcément clair ce que ça signifie CI CD ce que je veux demander à chacun d'entre vous c'est est-ce que vous avez un pitch elevator ou un punchline qui décrit rapidement ce que c'est la CI CD et on va repartir dans l'autre sens du coup maintenant. Alors Tug. Alors, pour ma part le pitch ça va juste être on va diminuer, on a accéléré le développement en déplaçant les tests le plus possible en automatisant le plus en plus de choses et c'est continuer sur ce principe-là en pouvant faire tous les tests possible toute l'intégration des différentes fibreries et si possible en fonction des besoins des projets déployés également donc déployés dans des environnements de développement en déployés dans des environnements de tests ou des environnements de production et c'est tous les outils qui tournent autour de ça quand on parle de la CI CD. Ok. Vincent, tu as une définition à nous proposer ? Moi je n'ai pas de pitch parce que je suis un dev mais non en fait la CI pour moi c'est vraiment l'automation automatiser tout ce qu'on peut automatiser en termes de build et bien sûr c'est vrai que la qualité de nos projets de nos produits soit là et la CI CD c'est le problème toujours à définir parce que on va continuer de livrer déjà on va continuer de déployer donc en fait CI CD ce n'est pas clair exactement ce que c'est mais l'idée c'est de pour faire vraiment simple c'est tu builds, tu déploies on continue et l'idéal ça c'est effectivement d'automaxier d'être capable d'être capable de produire quelque chose et de le livrer quand on veut et quand on veut et... Philippe alors moi je vais repomper un petit peu ce qu'on disait chez mes anciens petits camarades chez cléber clard si tu vas sur la home page la première phrase c'est iterate faster désolé pour l'accent globalement c'était ce qu'on disait et ça correspond à la CI ou la CD pour moi CI et CD c'est presque la même chose qu'il y a que les objectifs qui ne sont pas les mêmes c'est que si il y a quelque chose que tu sais faire à la main et que tu le fais 10 fois par jour trouve une solution pour l'automatiser et que t'es plus à le faire à la main donc pour moi la CI et la CD c'est vraiment courant comme résumé mais ça va me permettre de faire plein de choses que ce ne soit plus moi qui fasse ces choses là en fait, que ce soit fait automatiquement et comme ça ça évitera quelques erreurs si un matin je suis mal réveillé d'aller droper la base de prod par exemple ça ne peut plus arriver ça permet de se concentrer sur ajouter de la valeur tu disais que t'étais développeur ça c'est un truc de commercial oui mais je vois je vois aussi un peu ça non c'est les uns qui ne vont pas vous prendre votre métier vous allez pouvoir vous concentrer sur la valeur ajouter de votre métier on disait ça aussi chez Clever ok chez Clever j'étais sales ok bon après c'est pas quelque chose de nouveau la CI et CD moi Jenkins moi quand j'entends CI et CD j'entends Jenkins c'était quoi le premier nom encore avant qu'il se dû changer c'était Mister Hudson et avant ça pour être honnête le tout premier outil que j'avais c'était à l'époque c'était Continuum à l'époque j'étais chef de projet donc je faisais faire ça à l'équipe je savais pas comment ça marchait continue donc c'est quelque chose de pas nouveau pourtant j'entends souvent aussi dire oui mais pour que la CI et CD soit efficace dans votre entreprise il faut qu'il y ait déjà la culture un peu de DevOps qui soit implémentée parce que les devs et les ops vont devoir travailler ensemble sur cette partie-là est-ce que vous avez un avis là-dessus oui qui veut commencer vas-y oui alors j'ai un avis alors ce que tu viens de dire c'est vrai mais pour moi c'est le truc total final le plus gros échelon des choses à atteindre c'est pas la peine de faire un big bang dans une entreprise si déjà ça tu sais pas enfin si tu n'as pas ça au début c'est de faire qu'on sorte un petit peu du concept où il n'y avait que quelques spécialistes de Jenkins ou d'outils similaires et qui s'y connaissaient en réseau, en système et c'était eux qui t'installaient ta CI était obligé d'ouvrir les tickets pour demander des modifications l'objectif maintenant avant d'être dans un mode complètement DevOps c'est de simplifier le plus possible les outils CI pour que les développeurs puissent les utiliser en collaboration avec les ops ou les admin CI sont les appels comme on veut mais que justement les spécialistes puissent donner un degré d'autonomie au développeur sans que les développeurs viennent les enquiquiner toute la journée pour faire des changements ou sans que les développeurs soient obligés d'attendre la disponibilité justement de ces personnes qui ont d'autres choses à faire et qui sont justement concentrés sur la valeur ajoutée de leur métier et du coup de fournir ces ces outils ou ces petits bouts d'automation qui permettent au dev de pas attendre et de faire un petit peu les ops de leur côté leur permet d'être plus tranquille et puis d'aller bosser, je sais pas sur la spécécule de l'infra ou des choses comme ça donc pour moi DevOps c'est pas obligatoire c'est bien si les spécialistes savent donner des outils ou non spécialistes pour les aider à bosser une manière plus smooth, enfin plus tranquille et du coup je sais plus si c'était Tugue ou Vincent qui disait ça mais qui parlait de cycle continu ça permet d'avancer un peu plus sans aller jusqu'au je comite ça fait le test, ça déploie ainsi de suite parce que il y a certaines boîtes qui veulent mettre un step manuel on va dire pour des vérifications et c'est compréhensible au moins toute la période de dev avant même de faire une release que les gars soient pas embêtés, le développeur il doit développer et pas être bloqué par plein de trucs compliqués j'avais aimé quand j'avais en fait DevOps c'est arrivé un peu plus récemment il y a quelque chose que j'avais aimé quand j'avais travaillé chez Exo Platform avec Dimitri Bailey et Arnaud Hérithier qui est sur CloudBiz et sur Jenkins ils avaient sorti en tout cas je peux peut-être que vous l'aviez attendu avant mais moi j'avais bien aimé quand j'avais discuté avec eux la software factory chez Exo qui était une release, ça doit être un non-événement et en fait en partant sur cette chose-là c'est qu'est-ce que tu dois faire dans ton usine logicielle, dans les outils que tu mets à disposition des développeurs des testeurs à l'époque on divisait les deux des testeurs, des gens qui étaient ops pour que justement le code il puisse partir en release ou en production à n'importe quel moment et c'était mettre en place ces outils-là donc l'effet final pour moi effectivement a une équipe ou une organisation qui est DevOps mais c'est pas nécessairement un pré-retil en fait c'est plus se dire moi en tant que développeur moi en tant que ops, moi en tant que QA moi en tant que machin, il faut que ce soit complètement transparent qu'on partage tous les mails outils et la même façon de travailler OK, ouais Vous le réagir entre sur vos trucs respectifs Moi je suis plutôt d'accord avec les factudes, on utilise des outils qui sont plutôt des racines similaires et du coup ouais, à part dire je suis complètement d'accord avec ce qu'il dit je suis pas d'autre marre OK, je fais un petit tour sur le trait vas-y, vas-y, vas-y après il y a quand même quelque chose ça n'empêche pas que dans une équipe après on a des compétences et des centres d'intérêt qui vont être différents c'est-à-dire que moi avant de rentrer la partie CIA et la partie CEDI je m'en occuperai pas, c'est-à-dire que tu arrives sur les projets il y a des personnes qui ont travaillé sur les jobs qui vont bien il y a des personnes qui ont les compétences et malgré tout les gens qui vont faire du provisioning sur ton cloud qui vont faire ton terraformo équivalent qui vont faire tout le packaging, toute la sécurité sont au moins au début des personnes différentes du corps développeur qui travaillent en rubis, en java en coarcus sur autre c'est-à-dire les différentes compétences et la façon de travailler sur les projets il y a quand même un petit peu de différence entre quelqu'un qui va être plus de variante et hop ce que quelqu'un qui est variante et pure puis c'est la ligne pour l'application ok je fais juste un petit tour sur le chat parce que ça chat en compte chat je commence avec la petite blague de Gaëlle j'ai trop saigné avec Jenkins oui ça marche avec Jenkins j'ai trop saigné avec Jenkins ça marche mieux ça marche mieux oui en plus j'adore tectana moi j'aime bien Jenkins c'est ce qu'il m'a tout à pris en CIA tous les concepts je les ai appris grâce à Jenkins il y a Rarno c'est bien aussi qui rappelle que parfois on n'a juste pas d'outil on a déjà un skip bash et c'est déjà mille fois mieux que ce qui c'était avant j'ai connu j'ai travaillé dans des grosses boîtes de grosses assurances j'avais aucune... le build se faisait sur une des machines du dev tu prenais le e-r-file pour que tu mettais sur un répertoire partagé Windows et tu envoyais le mail à l'équipe Ops c'est sur ce smartphone attention on a rajouté quelques genres des slashes attention c'est toujours pas fixé c'était... et Thierry qui nous dit... du coup si CI-CD c'est quand tu automatises tout le code c'est de la CI-CD oui c'est le code qui gère du code pour atteindre un jour le non-code d'égal et ce jour là je prendrai ma non-retraite conclut Thierry j'aime bien sa petite enchaînement Jenkins qui a montré un petit peu le chemin pour ça la direction de finalement ta CI-CD c'est du code avec les Jenkins files c'est du groovy dedans et qui finalement ça a commencé à parler beaucoup plus au développeur que de passer d'écran en écran à faire des paramétrages, à oublier moi je me souviens j'avais l'impression que Jenkins faisait des blagues et que les écrans de config changaient quand je revenais parce qu'il y avait trop de choses pour moi mon petit cerveau n'arrivait pas à se concentrer et un jour j'ai vu Arnaud c'était web today à Nantes qui parle des Jenkins files et ça ça m'a sauvé la vie quelques temps après quand j'ai eu à faire un setup GitHub Jenkins me suis rappelé des Jenkins files et je suis devenu accro à cette idée là tout de suite et du coup effectivement la CI-CD c'est devenu du code avec des objectifs un peu différents de ce qu'on connaît maintenant mais je pense que pour des dev c'est vachement plus facile à assimiler et à comprendre ouais et il y a Arnaud qui lui vient avec sa définition pour moi le CI-CD sert cet objectif ne pas stocker le code dans un dépôt sans qu'il ne soit déployé de façon automatique et sur la prod un code écrit et il ne sert à rien oui le code tant qu'il n'est pas en prod il n'existe pas oui mais le code ne peut pas être déployé de façon automatique partout je pense qu'il y a une partie où on est encore loin pour beaucoup d'applications beaucoup d'organisations il y a plein de raisons pour le faire par contre qu'il soit capable d'être buildé préparé pour être déployé c'est pour ça tout à l'heure Vincent parlait de déployer ou delivery c'est à dire qu'à la rigueur peut-être que ton outcome c'est un jar, c'est un ER, c'est un binary quel qu'il soit et là tu es prêt à déployer mais le déploiement lui-même pour plein de raisons ne peut pas nécessairement être automatique mais par contre l'objectif effectivement c'est tout le code que tu meurs il doit servir avec quelque chose il doit être testé et il doit être package quelque part pour être potentiellement utilisé oui justement je pense que ce qui est important quand on va discuter avec des entrep... c'est-à-dire que quand on va parler d'igros du web etc eux font du déploiement continu ils déploient tout le temps mais quand on va aller travailler sur des projets un peu historiques avec des équipes justement qui sont habituées à avoir une mise en prod tous les trimestres comment on prend cette organisation-là pour la déplacer vers quelque chose qui s'accélère, c'est-à-dire que si on arrive à passer d'un déploiement par trimestre à un déploiement par mois à un déploiement par semaine c'est un gain qui est énorme pour tout le monde et donc si on arrive en disant on va faire du CI-CD ils vont se fermer comme des années voines sous la mer on n'y arrivera jamais donc il y a cette partie-là où on les accompagne et justement les outils avec lesquels on travaille tous c'est pour essayer aussi de donner un peu plus de pouvoir aux équipes de développement pour montrer qu'ils peuvent prendre en main le plus simplement possible pour commencer à dire, regardez nous de notre côté quand on écrit du code on l'a écrit, on l'a testé on l'a testé dans plusieurs environnements c'est-à-dire quelque chose de basique je veux pouvoir tester avec Node 3 versions Node, 2 versions Java avec la version Quarkus ambinaire la version Quarkus en jarre la partie CI-A va être capable de faire ça la compiler, la tester dans plein d'environnements pour pouvoir dire je prépare par la suite le travail suivant qui va être le déploiement qui dans un premier temps peut rester une fois par semaine, même si moi en développement j'étais prêt avant et du coup, je vois une remarque de Gaël là aussi elle fait junking, c'est chouette au final, mais le souci c'est de le maintenir je trouve et du coup ça nous emmènera tout à l'heure à la discussion des services proposés par GitLab, GitHub des services de CI-CD manager mais avant ça il y a une question de Thomas qui est assez intéressante est-ce que c'est mieux de spécialiser la conception de ces jobs à un DevOps ou un bureau, ou bien de confier la tâche aux devs et à l'équipe enfin, je m'avance à répondre ça dépend, mais elle est intéressante la question au début c'est moi j'aime bien à l'équipe, ça rejoint DevOps après c'est pour des jobs et des gens qui maîtrisent l'architecture je pense que c'est mieux de confier toutes les parties de jobs qui vont être utilisables, réutilisables à des spécialistes par exemple les DevOps ou à des gens qui s'occupent de la sécurité tout dépend les cités dans l'armée j'imagine qu'en termes de déploiements et de choses comme ça il y a des choses très importantes à faire et après, comme disait Tug c'est laisser l'attitude aux développeurs pour utiliser ces outils les développeurs comprennent quand même que quand il va déployer quelque chose ça a des impacts il n'y a pas que son code il faut qu'il ait la compréhension quand je déploie ça, ça va poper 3 VM ou 2 pod ou j'en sais rien donc c'est bien si la vision des quelques commandes qui sont lancées après toute la c'est comme pour Git les commandes de plomberies de Git moi je les laisse à des spécialistes les commandes de plomberies de CIA tu fais du Gitforce toi la, moi j'ai une anecdote là dessus t'as pas besoin de plomberies toi ? non j'ai pas besoin je suis en train de rédiger un kit de survie Git ça me parle beaucoup mais je pense que toutes les choses compliquées il faut les laisser aux spécialistes qui vont filer qui vont filer après des helpers ou des tools ou juste des fonctions que les devs vont pouvoir utiliser en faisant un peu des jeux de construction en fait pour arriver à eux ce qu'ils veulent faire par contre là dessus c'est à dire que si tu prends une équipe de devs un junior qui n'a jamais fait des devs qui n'a jamais rien mis en production même si tu veux faire du DevOps il faut avoir la compétence pour avoir déjà de ce que savoir sur quoi tu déploies demander à des développeurs qui travaillent en société de service sur quoi est déployé votre application en termes d'infrastructure il y a plein de fois vous allez ne pas le savoir par contre ils ne vont pas le savoir par contre ce qui est important je pense c'est que tous les scripts de DevOps tous les scripts d'automatisation et moi je mets automatisation d'une façon générale parce qu'il y a plein de choses qui le provisioning avant est-ce que ça fait partie de la CA ou pas ça peut faire partie d'un environnement ce qui est important je pense c'est que ce soit accessible à tous les développeurs pour qu'en fait comme un projet open source c'est à dire qu'on voit ce qui se passe dans une entreprise on partage ces ressources là les gens peuvent apprendre en lisant peuvent contribuer on fait une poudre equest sur une partie CA où on veut un commentaire on fait de la revue de la même façon à s'implifier ou à améliorer l'application on peut améliorer la partie automatisation et contribuer et apprendre ce qui est important c'est que dans la partie où quand on va merger du code qui va partir donc là c'est encore plus important parce que ce parti là va générer des choses en production c'est que ce soit contrôlé et bien revu c'est à dire que moi en tant que développeur Java ou Node je vais pouvoir merger du code qui sera sur du code applicatif et la partie les scripts qui mettent en production le merge on va laisser ça à la partie SRE ou à la partie équipe à côté qui dans l'équipe qui a le plus la compétence autour de bonnes parties parce que Vincent tu veux ajouter quelque chose à pas vraiment tout à été dit j'avais évoqué quelques points mais mets-tu des pieds pour un très bon job donc moi je connais c'est pas l'instant et comme le chat dit Sébastien Dupierre qui dit qu'on a déjà une CICD sur les environnements de préprod ou de dev c'est déjà c'est déjà une très bonne chose c'est ce qu'on essaye nous aussi moi c'est ce que j'ai on essaye de faire chez Radat par exemple pour juste déployer ces warplods et essayer de donner ce sentiment de self-serving aux gens qui puissent toucher un peu, voir ce qui se passe quand ils déploient leurs warplods et je pense que ça compte aussi pour la question chez une CICD en préprod et qui casse tout c'est pas très grave mais au moins ils peuvent apprendre sur leurs erreurs et adapter là-dessus je pense que c'est c'est déjà une très bonne chose, oui pousser en prode directement ouais ça se fait c'est ton métier tous les jours ça Sébastien toi tu fais de la déploiement continue pas que pas je vais déployer je fais du déploiement je fais du déploiement de paillettes je voudrais réagir sur un commentaire qu'a fait Gael Gael écrit Jenkins reste privilégié dans les boîtes qui ne veulent pas mettre leur prédential dans le cloud en fait c'est pas totalement vrai Jenkins reste privilégié parce que c'est la plateforme d'intégration historique c'est-à-dire c'est déjà assez présent dans beaucoup beaucoup d'entreprises il y a énormément énormément de pipelines qui ont déjà été présents et réécrire un pipeline sans valeur ajoutée en passant sur une autre tête pas nécessairement de la valeur tout de suite par contre ce concept de dire je veux pouvoir exécuter certain job chez moi et non pas sur le cloud dans un environnement on va dire confiné c'est peut-être pas le proterme mais aujourd'hui toutes les solutions permettent c'est-à-dire que quand peut-être que Vincent là ça sera l'occasion que tu rentres dans le détail un petit peu de ce que fait Tecton par rapport actions si il y a une quand tu travailles avec GitHub ou GitLab tu peux exécuter tes jobs même si tu utilises une version manager et mettre toutes tes crédentiales en local mettre toutes tes bases de données en local sans avoir rien sur le cloud ou alors déployer la solution complètement on-premise c'est-à-dire que c'est vraiment aujourd'hui justement ça fait partie des choses qui ont été importants dans la mise en place des outils c'est cette compréhension que des entreprises quand on va toucher aux entreprises que demain et tous les jours on voit que ça bouge vers cette direction mais Jenkins n'est pas la solution unique pour le faire heureusement d'ailleurs du coup merci Toc pour la transition parce qu'on va parler un peu plus des solutions CI-CD dans le cloud et manager on va on va aborder les deux en même temps et on a évoqué déjà plusieurs fois Tecton Tecton je sais pas comment le dire en français mais peut-être toi Vincent c'est l'occasion de faire là pour le coup je pense que tu as un elevator pitch pour Tecton et ouais Tecton en fait moi je dis Tecton comme je le dis en anglais en français c'est trop compliqué de switcher Tecton c'est ni plus ni moins que se dire les gens utilisent et sont habitués à Kubernetes en tout cas pour les gens qui sont habitués pourquoi ne pas leur fournir un ensemble de composants qui fonctionnent de la même façon que ce que eux ils ont l'habitude les IML, les objets, les CRD etc qui sont un cube mais ça leur permet de définir leur pipeline et du coup d'essayer de passer d'un Jenkins qui est un peu monolithe qui gère tout à un truc où tu définis tes pipelines tu partages un peu tes définitions etc mais au moins tu laisses la partie orchestration à cube parce que cube étant déjà un orchestrateur on a juste besoin de de les ségérer en fait donc voilà après pour faire vraiment très très simple c'est ça Tecton c'est des objets plusieurs composants qui fournissent des objets cubes qui permettent de définir des pipeline et ça peut être utilisé pour le CI ça peut être utilisé pour le CI ça peut être utilisé pour ML, ML c'est quoi déjà machine learning on a des gens chez IML qui utilisent Tecton pipeline pour faire du machine learning puisqu'on a essayé quand on a fait Tecton de faire un truc qui est relativement abstract pour que ça puisse être utilisé dans plein de use cases différents petit à petit on le voit les besoins qu'on a et on crée d'autres structures et après ça va être déclenché c'est-à-dire que tu vas le pluger sur un repo-guide par exemple les événements qui vont arriver vont commencer à déclencher des pipelines de la même façon et en fait au départ il n'y avait que Tecton cd pipeline qui vient du projet qui est native build et donc au début c'était vraiment juste cette partie pipeline et quand on s'est dit tiens on aimerait bien upstream donc dans la communauté on aimerait bien utiliser Tecton pour build Tecton parce que si on n'utilise pas ce qu'on fait c'est un peu dommage on s'est dit tiens il nous manque quelque chose pour gérer les événements qu'on a qu'on a native eventing mais on voulait un truc plus simple donc on a créé un composite et après on a commencé à mettre en place ça on s'est rendu compte qu'on voulait stocker des résultats en gros il y a beaucoup de choses, beaucoup de features qui viennent du besoin lui même de Tecton et maintenant d'autres d'autres customers d'autres clients maintenant IBM support déjà Tecton Google je ne suis pas sûr là tu parles déjà Tecton il y a pas mal de des trucs comme ça donc oui je vais dire sur sur sur Tecton par exemple dans OpenShift nous ça nous simplifie par le but c'est que ça nous simplifie énormément la tâche par rapport et au client par rapport à la gestion de Jenkins Jenkins déployé dans OpenShift c'est c'est horrible à maintenir ça consomme beaucoup de beaucoup de ressources la plupart des besoins clients par exemple c'est je veux un Jenkins par équipe parce qu'en fait si j'ai pas un Jenkins par équipe j'ai une équipe qui va vouloir ce set de plugins une autre équipe qui va vouloir ce set de plugins et ça devient un enfer à maintenir et bah plus on en déploie plus ça devient un monstre de ressources au contraire Tecton on essaie d'inmercer parce que c'est un truc très lightweight et on dit bah voilà toutes les spécificités que vous avez qui seraient exprimées par les plugins en fait maintenant c'est des tâches c'est des trucs qui vont se passer dans des conteneurs c'est des trucs que vous avez que vous pouvez facilement partager il y a tout cet aspect là normalement et tout tes ressources quand tu demandais une question sur le déclenchement il y a des triggers des ressources triggers mais même t'as une ressource qui s'appelle Task Run ou Pipeline Run c'est une ressource que tu appliques sur ton container qui va déclencher ton pipeline donc là encore tout est sur la philosophie de déclaratif même le déclenchement c'est du déclaratif, une ressource ça c'est un choix design qui est assez important dans Tecton c'est de se dire quand tu définis ton pipeline tu as ton pipeline, tes tâches et dans chaque tâche tu as des steps quand tu définis ton pipeline et tes tâches tu définises qu'elles peuvent faire ce qu'elles vont faire mais quand tu les appliques à ton cluster ou quand tu les définis dans ton cluster elles ne font rien en fait elles sont utilisables derrière nous on sépare vraiment la partie définition que je veux exécuter ce pipeline ça permet du coup par exemple un pipeline qui est très générique et qui va permettre à une équipe de déployer différents workloads en utilisant le même pipeline juste en changeant des paramètres ou en changeant de ressources et ce qui fait là je vais prendre une cascade très Github dans la construction ce qui rend difficile dans certains cas l'évolution de la solution Jenkins vers Github Action c'est qu'en fait Jenkins a une palanquette plugins qui est énorme énorme énorme et Github a les actions je pense que Githlade va avoir pareil un système d'extension et de plugins qu'est ce qu'il y a Tecton est plus récent qu'aujourd'hui en termes d'intégration si tu veux faire de la code qualité du DevSecOps pour analyser ton code en sécurité c'est un équivalent je suppose sur Tecton pour rajouter des choses ça dépend oui et non il y a des tâches donc en fait dans Tecton il y a une partie d'organisation des tâches qui peuvent être utilisables ça va être créer une pour le Github ou un Github ça va être communiqué via Slack c'est un ensemble de tâches qui peuvent être très facilement partagés avec tout le monde il y a une UI qui s'appelle Hub et du coup petit à petit la communauté vient et ajoute des tâches donc il y a des tâches de DevSecOps pour analyser du code avec sync ou d'autres trucs donc ces petits à petits l'idée c'est que ce catalogue de tâches grandissent que d'autres boîtes aussi puissent fournir leur catalogue par exemple Google puissent fournir des trucs spécifiques Google Cloud Amazon pareil, Github des trucs aussi l'idée c'est un peu ça même OpenShift on a notre propre catalogue avec certains trucs optimisés pour OpenShift l'idée c'est petit à petit que les développeurs ou les gens qui utilisent Tecton puissent se dire j'ai besoin de ça j'ai besoin de ça, moi je fais mon pipeline mais je prends les tâches qui ne sont pas partout et pour reparler du lien avec Jenkins effectivement il y a un truc très important que nous on voit avec nos clients ils utilisent Jenkins ils trouvent Tecton super intéressant mais c'est un gros big bang si on veut tout passer de Jenkins à Tecton et donc l'idée c'est de se dire comment on peut les aider à passer de l'un à l'autre CloudBiz avait fait un petit projet pour essayer de traduire des Jenkins files de manière automatique en définition Tecton c'est un enfer c'est très compliqué parce qu'il y a beaucoup de customisations qui se font par contre il y a deux projets qui existent qui sont sortis assez récemment de trucs distincts un Tecton plugin un autre plugin dans Jenkins permettant d'exifter un pipeline une place run ça permet de commencer à écrire quelques trucs en Tecton tout en utilisant Jenkins ou l'inverse utiliser un Jenkins runner il y a une tâche Jenkins runner qui nous permettrait de faire un pipeline il y a une partie du pipeline qu'on a déjà transféré en Tecton il y a une partie du pipeline qu'on n'a pas encore eu le temps de transférer on le met et c'est le Jenkins pipeline qui va au bout de se rappeler le truc avant de poursuivre parce qu'on me fait signe dans l'Oreate qu'il y a des questions dans la section Q&A il y a deux questions je commence avec celle-là est-il prévu un éditeur graphique de pipeline Tecton plutôt que l'édition des fichiers à plat et à meule alors je vais te laisser répondre mais si tu utilises OpenShift tu as déjà cet éditeur disponible j'allais dire la même chose dans OpenShift il y a le builder qui n'est pas tout à fait en ce moment en tout cas il aga un tout petit peu par rapport au feature de Tecton sur que Tecton a dernièrement 16h25 l'éditeur il supporte il y a des files qui supportent pas encore qui supportent dans la prochaine release il y a aussi le plugin VS Code de Tecton qui est un builder visuel c'est les deux que je connais il y a peut-être d'autres trucs après pour l'instant c'est des projets communautaires Open Source qui sont portés par Red Hat et Red Hat est quasiment l'unique contributor il n'y a pas de projet il faut que l'on soit adopté upstream dans la communauté Tecton pour l'éditeur graphique d'un moment le focus là dessus c'est plus pipeline Ascode que vraiment l'éditeur graphique parce qu'on a beaucoup plus de demandes sur la partie Ascode que sur la partie édition graphique il faut réussir à motiver des développeurs front et UI autant sur la partie monitoring, alerting la partie UI est très importante pour comprendre rapidement ce qui se passe pour pouvoir voir quel workflow que tu as développé et qui a tourné au niveau du développement on s'aperçoit qu'effectivement ça permet une prise en main plus simple mais dans la réalité une fois que les gens ont commencé à s'habiter et pourtant je suis loin loin d'être un fan de Yemen parce qu'en fait c'est beaucoup de compositions effectivement ça pourrait être de la composition graphique parce qu'au bout du compte dans la réalité que tu le fasses dans du code ou dans une interface graphique ne change pas grand-chose sauf que développer une interface graphique très chère il y aura toujours cela avec on a rajouté ses fonctionnalités ses attributs et un chat donc je pense que c'est moi je trouve que c'est une fausse bonne idée parce que moi je pense que c'est important de comprendre ça semble derrière l'intermédiaire en fait effectivement c'est une fausse bonne idée il y a du dessin de pipeline à la main mais ça rappelle ce qu'on faisait au début de Visual Studio.net on pouvait construire ses pages STX aux clics et à la souris et après tu avais juste quelque chose d'un maintenable parce que ça générait un code source de folie là c'est pareil moi honnêtement en Iyamel j'ai appris à l'aimer maintenant j'adore je dis pas que je rêverai en Iyamel mais c'est pas loin quand on voit ce qu'il faut faire pour faire du cube de toute façon on s'aperçoit que pour l'instant le Iyamel on peut difficilement s'en servir ce qu'on a proposé pour les runners Gitlab c'est pareil on décrit ce qu'ils ont à faire en Iyamel ce qu'on a proposé mais ça fait pas longtemps parce qu'effectivement plein de gens demandaient ça c'est une preview de à quoi va ressembler le pipeline parce que avant tu lançais ton pipeline et c'est là où tu avais la preview ou globalement ça te compilait le Iyamel et ça te dessinait ton pipeline et ça l'exécutait là avant même de l'exécuter t'as une preview avec les dépendances des jobs pour voir si t'es pas en train de puis un linder aussi pour voir si t'es pas en train de faire une connerie et je voulais juste rajouter et du coup c'est assez pratique mais surtout pour les gens qui débutent moi j'avoue que je m'en sers pas et je voulais juste rajouter des plugins en fait dans GitLab dans GitLab CI il n'y a pas de plugins t'as des features autour de GitLab qui sont liés à différents sujets que tu pourras utiliser à partir de ta CI mais il n'y a pas de plugins c'est juste à partir de Iyamel tu vas pouvoir faire, enfin exécuter des jobs mais il faut t'imaginer que les runners c'est des environnements qui sont une machine donc ça peut être un runner sur une VM ou même sur du bar métal ou dans un container le runner va utiliser les ressources de l'endroit où il est installé donc c'est à besoin d'outils tu les installes sur ta VM dans ton container c'est pour ça qu'on en utilise de plus en plus avec les containers c'est facile et dans le job à l'autre tu peux changer l'image dont t'as besoin tu te fais tes outils quelque part tu te fais tes propres plugins on est vraiment allés au plus simple et du coup même moi au tout début en utilisant j'ai installé mes runners sur des vraies machines après je suis passé sur des VM c'est super facile parce que tu peux reproduire ce que tu fais tu évites un peu les faits mais je comprends pas ça marchait sur mon poste donc monter des runners sur du bar métal c'est pas forcément une bonne idée sauf pour des choses spécifiques comme pour de l'infrascode et puis après il y a monter des runners qui savent utiliser du docker ce qui permet après d'aller plus vers une fois que t'as toute cette mécanique de faire plus facilement du cloud native et d'aller balancer tes runners dans du cube par exemple du open shift et là en plus de la reproductibilité tu vas gagner l'ascalabilité donc nous les runners ils sont tout bêtes ils sont tout cons mais comme ils sont tout cons c'est facile de les déployer des runners dans tous les sens ouais cool je regarde la Q&A alors je sais pas alors il y a Sébastien qui demande quelle est la vision dans 3 ans avec la porte des IA I4 code alors est-ce qu'on peut imaginer je vois pas si il y a un impact sur la CI-CV bah ouais tu disais tes runners un peu con cons est-ce qu'ils vont pas vouloir je pense qu'ils vont rester cons je pense que c'est quelque part c'est le mode de fonctionnement de la CI-CV on a tous des modes de fonctionnement les logiques me semblent similaires moins ma vision alors elle n'engage que moi c'est que les runners vont rester cons, c'est juste des passplats et des exécuteurs de tâches mais on parle beaucoup de sécurité de sastes par exemple et on en fait tous quelque soit les produits pour aller analyser la qualité la recherche de minerabilité dans le code on pourrait imaginer parce que sastes ça va te donner des conseils en disant attention c'est pas bien d'éclater un code comme ça parce que si tu peux mettre dans un réval en JS tu peux lancer ce que tu veux tu pourrais imaginer alors je sais pas quel nom on lui donnerait si ça se trouve ça existe déjà mais qui est un espèce d'analyseur qui dirait ton code COBOL pour le migrer en Kotlin Vertex eh ben ça serait bien que tu fasses ça donc je pense que l'IA pourra servir à t'aider à améliorer ton code après peut-être que l'IA aura et là ça serait plutôt du machine learning mais c'est pas du tout mon domaine donc j'extrapole mais peut-être que l'IA pourrait aider plus sur le côté infras pour arriver à optimiser les ressources d'exécution parce que je vois plus c'est les... pardon vas-y non non c'est ça c'est une partie qui serait sur le code c'est-à-dire l'optimisation du code il faut dire de l'intelligence quand tu codes t'aider à écrire du code le plus tôt possible capturer les problèmes sur ton algo que t'es en train de coder et l'autre partie c'est à la rigueur peut-être optimiser la même façon que ça peut être fait sur du code faire ça assure tes pipeline pour optimiser le pipeline et ensuite il y a quelque chose qui est autre qui est sur l'infra proprement dit c'est comment tu gères la scalabilité l'optimisation de ta scalabilité pour faire du scale up, scale down toute l'élasticité et là ça serait vrai pour des runners ça serait vrai pour tes applications et même avoir l'optimisation après faut arriver à mesurer à quel point actuellement cube est suffisamment intelligent pour faire le scale up, scale down ou les outils qui tournent sur cube qui est native normalement je connais que la partie serving mais jusqu'ici ce que j'en ai vu l'élasticité est super bien fait super bien géré, est-ce que c'est suffisant est-ce que sur une grande échelle quelqu'un qui aurait je sais pas comment on dit pour tecton mais on va dire 8000 quints est-ce qu'on a aujourd'hui suffit pour le rendre élastique intelligemment ou est-ce que justement on aurait besoin de machine learning ou d'intelligence artificielle ce qu'on voit aujourd'hui dans la communauté par exemple des runners une partie qui est 100% cloud géré par github quand vous avez un projet open source c'est géré par exemple 100% par github il y a une partie où tu peux installer tes runners et il y a tout un effort autour de la communauté kube pour avoir les runners qui sont gérés au scale tout zéro la mise en place des nouveaux runners de façon sécurisée avec ton repo aujourd'hui il n'y a pas d'intelligence ce n'est pas de l'intelligence artificielle ça arrête de la config par exemple tu vas avoir en fonction de la cpu qui va être utilisée les mêmes métriques que tu fais quand tu fais du pod classique mais pour tes runners de Sierra ok une autre question d'Amien, intéressant du coup parce que ça apporte l'aspect github il dit si on devait comparer Tekton avec Argo workflow les pour et les contre de chaque outil alors je sais qu'on peut faire de l'argo cd donc du github avec Tekton parce que je le montre même dans mes démos mais Vincent tu as un un avis là ? ouais là c'est Argo cd c'est Argo workflow un workflow qui est relativement similaire dans son approche à Tekton dans le sens où c'est pouvoir exécuter ces jobs dans le cube j'ai moins utilisé que Tekton c'est normal je pense mais j'ai un petit peu utilisé la vraie différence pour moi c'est qu'il n'y a pas ce split definition runtime et ce split task pipeline donc en gros on définit son workflow ou alors je ne sais peut-être pas les seins non plus mais pour moi c'est on définit un workflow il y a des paramètres il y a un aspect un aspect graph d'exécution comme dans Tekton le truc c'est que c'est un objet on définit son truc dedans quand on le met c'est exécuté j'ai pas vu l'aspect partagé ces workflows etc pour moi c'est la grosse différence dans ce que je connais après sinon l'approche est la même et pour moi l'approche même de GitLab GitHub, tous les nouveaux CIA ou tous les CIA cloud il y a un truc sur lequel tout le monde s'accorde que j'adore c'est de se dire en fait l'intelligence elle n'est pas dans les plugins dans les machins mais dans les containers et on partage tous la même vision et donc si on fait des images correctes avec ce qu'il faut dedans en fait les utilisés dans GitHub Action les utilisés dans GitHub Runner les utilisés dans Tekton c'est pas assez différent au final la syntaxe change un peu mais le reste est très similaire c'est juste une histoire de où est-ce que c'est déployé et quels sont les contraintes qu'on a etc et à workflow ça fait partie d'une des solutions que je mettrais similaire à Tekton pour moi elle est un peu moins puissante dans son aspect partage de définition et de l'exécution de machin mais ça a l'air pas mal ok et du coup sur ce partage des visions j'aime bien et attention je ne vais pas trop les mais c'est plutôt une autopie et vous savez que vous avez déjà imposé la question en fait il y a quelques semaines j'avais lu je crois que c'était Max sur Twitter qui voulait faire marcher ses GitHub Action et à ce moment-là ça fonctionnait pas bon ça règle tant en tant comme tout et il a dit même c'est dommage j'aurais trop voulu prendre ses GitHub Action les balancer sur mon GitHub que j'ai aussi mais je peux pas faire ça et on avait lancé la description ah bah c'est GitHub et GitHub avait comme base Tekton tous les deux t'aurais pas ce problème à terme ce serait possible que ce soit la base commune à tous et vous GitHub, GitHub n'importe qui votre plus-value en fait c'est de manager le service donc le support peut-être je sais pas la scalabilité mais que la base soit la même est-ce que c'est quelque chose que vous pouvez penser, imaginer là c'est difficile en tout cas vu ma position c'est difficile de dire que ce soit sur ce dessus je pense pas parce que si on regarde la façon dont tu écris les workflow les pipelines de chaque côté c'est un peu différent la philosophie est un petit peu différente on a des composants réutilisables qu'on assente pour faire un pipeline donc tu écris une GitHub Action que tu la déploies c'est du JavaScript ou un conteneur docker ça sur la philosophie c'est la même sur l'implémentation c'est différent tout sur plutôt si on veut parler de cubes c'est d'être capable de faire en sorte que tes runners soient manager par du cube mais d'un autre côté aujourd'hui on peut pas nécessairement imposer à tout le monde d'aller sur du cube à chaque fois et tu as encore beaucoup beaucoup et c'est là où si on revient à la discussion pas la discussion mais au commentaire initial qui est un de mes commentaires qui était sur le côté Jenkins je vais utiliser un gros mot donc c'est un peu legacy et toutes les nouvelles solutions cherchent à simplifier cette partie-là le but c'est que faut que ce soit pas non plus si tu imposais avoir un Kubernetes pour pouvoir commencer à faire de la CIA avec GitHub ou Bitlab on remettrait une grosse barrière là où on lui dit bah non mais votre runner Jenkins vous le remplacer par un conteneur ou par un process dans une VM et vous pouvez faire la même chose et vous êtes sur votre SI de façon simple et que ça marche c'est compliqué cette partie-là sur le papier c'est top mais on vient tous du monde Java pas tous mais en partie du monde Java J2E même quand on avait une spec qui était la standard on n'arrivait pas à faire des trucs qui marchaient avec les autres donc imagine tu as pas de spec ah mais je suis plus vieux mais ouais je pense que l'interoperabilité donc c'est un des termes les plus difficiles à prononcer pour moi et d'ores et déjà possible alors tu as raison par contre on va être sur du cube en fait je pense je vais parler avec vision GitLab je pense que côté GitHub c'est à peu près pareil mais tu pourras compléter ce qu'on essaye de fournir c'est que notre CI il soit complètement intégré dans notre outil de gestion avec globalement quand t'es développeur tu sors pas de l'outil en fait t'es dans le même outil qu'il y ait un Tecton qui fonctionne aussi bien avec pour éviter le problème qui a eu tant d'amis Sébastien un Tecton qui fonctionne aussi bien avec GitHub que GitLab il faudrait qu'on ait une intégration l'intégration elle peut aider d'ores et déjà possible il faudrait que j'allais dire esthétiquement visualement parlant tant GitHub que GitLab sera capable d'afficher et d'éditer les pipeline Tecton directement au sein de GitLab enfin de l'interface utilisateur GitLab ou GitLab moi ça me pose pas j'ai pas de d'état d'âme par rapport à ça parce que tu prends des licences tu peux dire à pas plus cher si tu utilises GitLab avec Tecton j'ai plus en tête le modèle de pricing de GitLab mais je crois que c'est à peu près pareil sauf sur le cloud parce que tu payes des minutes de reneurs ça peut avoir un impact ouais ça c'est un préféré la vie de pas mal de monde après Vincent avait une bonne remarque sur met tes outils dans des containers et tu utilises les mêmes outils quel que soit ta CIA finalement ton travail d'écriture de script de CIA sera pas si violent que ça parce que tu déportes l'intelligence de tes outils et tu as juste des espèces de scripts façon bâche qui vont juste ordonner ça mais c'est pas si compliqué après c'est vrai que si on garde le il y a la problématique de je pense qu'on sera jamais on n'aura jamais tout le monde sur encul parce que c'est pas obligé parce que peut-être que d'ici là que ça arrive il y aura autre chose de nouveau qui sera sorti donc ouais c'est un sujet super intéressant c'est possible, l'avantage c'est que ça donne du boulot à tout le monde histoire d'interopérabilité donc moi j'aime bien moi pour rajouter un truc là dessus je pense que je suis d'accord sur le fait qu'à mon avis moi je me dis pas que GitLab ou GitHub devrait par exemple rendre accessible les API de Tecton, ça fait pas forcément sachant qu'on peut aussi inverser le truc et se dire bah tiens Tecton si on voit Tecton comme un ensemble de ressources partageables pourquoi est-ce qu'on pourrait pas exécuter un pipeline lui-même dans une GitHub Action ou dans un runner GitLab, sachant qu'il y a déjà réflexion là dessus dans la communauté Tecton parce qu'il y a déjà une réflexion sur avoir un local de Tecton en fait ça c'est déjà possible, alors quand je dis c'est déjà possible c'est peut-être pas déjà possible à Tecton mais tu prends par exemple sur GitHub Action, si tu as des actions pour lancer Azure Pipeline, pour rentrer Jenkins pour faire d'autres je pense que c'est plus, faut juste attendre un peu plus d'adoption je pense que c'est encore un peu tôt dans la communauté Tecton par rapport à l'adoption pour que cette action, là je vais prendre le vocabulaire GitHub mais pour que l'action exécuter un pipeline Tecton existe et ça viendra en fait, c'est-à-dire qu'à partir du moment où la communauté va commencer à faire ses jobs sur Tecton, le besoin va immédiatement devenir de dire je veux pouvoir faire ma city avec GitHub ou avec un autre solution mais je veux pouvoir lancer mon pipeline dans OpenShift avec Tecton parce que c'est ma solution que j'ai choisi et le point qui est intéressant et Philippe le veille tout à l'heure c'est-à-dire que comme GitHub, notre rôle c'est de fournir une plateforme au développement pas de l'imposer, la seule chose qu'on impose entre GIMA c'est Git tout le reste autour c'est quelque chose tu veux faire un issue manager qui est du Gira qui est du Trello, qui est du tu peux le faire la seule chose c'est qu'on est tous abonnés à Git on utilise Git et les événements les hooks que passent sur Git vont permettre de t'intégrer avec le reste du système mais évidemment moi je vais préférer si tout le monde utilise toute la stack il y a des features mais c'est pas nécessaire c'est intéressant à la rigueur on fait un recathon ensemble pendant tes vacances on a failli faire quelque chose ensemble il y a quelques mois mais à l'époque on travaillait dans la BB Team moi ouais je regarde juste les questions il y a une question il a déjà répondu sur XLDP, je ne connais pas il y a une autre question un peu plus technique je ne sais pas ce qu'elle pourra répondre t'as-tu à Philippe quelles sont vos opinions sur concours CI, je suis en 7.2 sur Kubernetes et mes worker runners sont Conternady et je me demande pourquoi je devrais changer vers GitLab CI alors j'ai pas d'opinion en fait parce que je n'utilise pas après pourquoi est-ce qu'il devrait changer pour GitLab CI alors à côté je dirais si t'es bien avec ce que tu as et que ça répond à tout ce que tu as besoin tu ne poses pas de questions, on ne change pas après si t'as des douleurs pique-moi en DM et puis on en discutera mais oui ce que je disais je n'ai pas d'état d'âme je suis content quand t'es un client ou quelqu'un ce n'est pas forcément client parce qu'on fait de l'open source utilise la stack complète, ça me fait plaisir je suis fier mais j'ai tellement de clients qui utilisent GitLab avec du Jenkins ça serait malvenue de ma part de dire ce n'est pas une bonne idée si ça marche puis tu le disais, il y a certains pipeline que t'as écrit en Jenkins t'as plus envie de les modifier on va pas être t'es pas obligé de migrer le seul commentaire que je ferais là dessus c'est toujours un pari qui est difficile quand on commence avec une nouvelle techno c'était je ne connais pas concours et je ne l'ai jamais vu donc j'ai aucune opinion la seule chose auquel il faut faire attention c'est de se dire si t'investis beaucoup sur une technologie et qu'il n'y a pas d'adoption d'une communauté derrière tu vas avoir du mal à recruter ton écosystème de plugins va peut-être pas être assez rapide et tu vas te retrouver bloqué non pas parce que la techno ne marche pas mais parce que son écosystème autour ne prend pas je sais pas qui se souvient encore et je peux m'en souviens la alternative qui avant que tu prennes le lead c'était Rancher non je trôle non et je suis désolé mais je vais faire conclut parce qu'il y a une autre track qui va commencer aussi et il va falloir que j'accueille Katya sur cette track là en tout cas c'était super cool super décision on est resté bien verrant cool je pense qu'on a bien discuté du sujet ça peut continuer sur le slack allez sur le slack si vous voulez poursuivre la discussion en tout cas je suis très content j'ai pas vu leur passer donc c'est un bon signe bon j'espère que c'était pareil pour toi merci