C'est d'abord une culture. Quand on est en DevOps, on prend tout le monde.
DevOps et agile font effectivement partie de la même famille.
Sa virtualisation applicative, c'est très bien.
Aujourd'hui, ça nous prend 10 minutes et un café.
Ce n'est ni être dev, ni être DevOps. C'est avant tout de la communication.
Ce mouvement DevOps, c'est tout simplement drivé par la communauté
et endorsé par les entreprises.
J'ai adopté une démarche DevOps.
Le développement agile, on a accéléré des poignements.
Ça amène une clarté sur le travail de...
Être dans une démarche d'amélioration.
Face à des...
Ça va naturellement ensemble, ça donne des résultats contrêts.
DevOps.
L'objectif individuel, ça s'atteint alors qu'une ambition, ça se partage.
Bonjour à tous et à toutes et bienvenue dans ce nouveau numéro de DevOps.
Alors aujourd'hui, nous sommes 3 pour parler des environnements ephémères.
Alors on va vous préciser un peu plus ce qu'on entend par environnement ephémère.
En tout cas, il fait suite au précédent podcast qu'on a fait avec Arnaud
sur les tests dans les infrastructures AsCode.
Et on va voir que ça a des liens et aussi des différences.
Donc on va essayer de voir ça un peu plus.
Alors aujourd'hui, j'ai Yann Xavier qui vont se présenter.
Yann, on va dire.
Ok, on va chanter. Yann, je suis co-fondateur et studio d'une boîte qui s'appelle Wise.
Qui permet en gros de mettre en relation des professionnels et qu'ils échangent autour de leur sujet.
Et dans notre aventure entrepreneuriale, on a mis en place les environnements ephémères,
notamment pour notre PO et qu'elles puissent tester les devs de manière à synchrone.
Et ton bac grand un peu, si jamais tu veux.
Alors moi j'ai fait classique une école d'ingénie que j'ai pas finie.
Et puis j'ai eu une agence web.
J'ai été directeur technique de Youscrib où j'ai rencontré Guilhem notamment.
Et mon truc c'est vraiment génial logiciel.
Plus web à la base.
Traier aussi beaucoup dans e-commerce pour se loger aussi sur la partie mobile.
Et voilà, je me suis mis dans l'infra un peu, pas la force des choses.
D'accord donc plutôt bac grand dev qui se met à faire de l'ops.
Exactement.
Super, ce qui ressemble beaucoup à Rnour de la semaine dernière que vous pouvez écouter.
Et donc Xavier qui lui pour le coup est un peu plus en habitué.
Oui voilà, Xavier Crans, j'ai déjà pu participer à des épisodes précédents de DevOps.
Donc moi je suis DevOps et sérieux pour une boîte qui s'appelle Virtuo.
Et Virtuo en fait c'est NextGenKRN.
En gros vous pouvez louer, ouvrir, déverrouiller, démarrer votre voiture à l'aide de votre automobile.
Très bien.
Et alors moi donc toujours Guilhem, je travaille longtemps que indépendant.
Pour différentes missions, pour des boîtes de toute taille, surtout sur Kubernetes etc.
Et donc comme les fois d'avant, n'hésitez pas à proposer de nouveaux sujets.
Des personnes sont venues pour voilà donc on va avoir des sujets assez cool qui devra arriver dans les semaines qui viennent.
Donc on a dit en introduction, en fait j'ai dit en introduction qu'on allait parler des environnements e-fémer.
Je lui demandais tous les deux qu'est ce que vous vous entendez par environnement e-fémer et comment vous les avez utilisés.
Xavier, alors un environnement e-fémer en tout cas tel et qu'on l'a implémenté chez nous,
c'est essentiellement une copie d'un environnement qu'on trouve déjà en production ou en staging.
Et là sa particularité c'est qu'on essaie de faire en sorte qu'il est dédié à une feature.
Et donc grosso modo on a une infrastructure un peu microservice.
J'ai dit un peu parce qu'il y a effectivement des microservices par contre, ils ne sont pas vraiment très très autonomes.
Ce qui fait qu'on a obligé de créer un environnement qui ressemble le plus possible à staging
et sur lequel en fait les versions des soft ont été buildées en fait depuis une feature branch.
Ok et il dure à peu près combien de temps dans vos environnements parce qu'on les appelle e-fémer.
Donc c'est bien qu'ils ont une fin, c'est à peu près combien de temps.
Alors malheureusement je ne pourrais pas donner de maitrisque sur la temporalité mais en gros c'est lié à une feature et une branche.
C'est à dire que pour créer un environnement e-fémer il te faut une branche
et quand la branche est l'emerger et dilite de github on dilite les environnements.
Très bien.
Et toi Yann ?
En fait ce que j'appelle un environnement e-fémer chez nous c'est pareil,
il y a un environnement qui est lié à une fonctionnalité,
qui est une réplication d'un environnement de staging ou de proie de classique
parce que de toute façon ça part des mêmes définitions d'infrastructure
et donc dédié à une fonctionnalité qui part d'une poulue request.
Et à partir de là on déploie cet environnement.
L'objectif de cet environnement c'est finalement que la fonctionnalité soit visible et testable par l'ensemble des stakeholders.
Ok, plus dans les détails alors avec eux ou les avez implementés sur...
Déjà pourquoi vous les avez fait ? Est-ce que ça a été quelque chose qui était là depuis le début ?
Est-ce que ça a été quelque chose qui est venu par la force des choses ?
En fait à la base j'avais un peu un classique staging qui était le Y staging
et puis qu'on utilisait pour voir un petit peu les fonctionnalités qui avaient été développées
notamment pour la PO et puis pour les autres fondateurs.
Et en fait ce qu'on s'est rendu compte c'est que des fois entre le moment où la fonctionnalité était finie de développer
le moment où il était testé il se passait un peu de temps et entre temps il y en avait d'autres qui étaient développés
et donc tout d'un coup ça posait la question est-ce qu'on fait tout tester en même temps de manière isolée
parce qu'il y a des trucs peut-être qui n'avaient pas parti en prod et il fallait un peu pas forcément tout merger tout de suite.
Et étant sur cube et ayant un environnement assez déclaratif
me suis dit ça me demanderait peut-être pas beaucoup de modifications d'en avoir un environnement par fiture
j'avais toujours trouvé ça intéressant aussi comme concept.
Donc c'est là où c'est né où je me suis dit pour justement contrebalancer ce truc
il y a un vrai problème de synchro entre la fin d'un dev et la visualisation de ce qui a été fait
il faut qu'il y ait plusieurs environnements en fait.
Ouais en gros ces environnements infémer c'est principalement d'environnement de recette justement pour le PO
et pour qu'il ait une fiture et nous on décoronne un petit peu cet endroit où on se concentre sur la fiture
et une fois que le PO est plutôt content ensuite on se concentre sur l'intégration et fait en sorte que tout va bien sur cet environnement qui est staging.
Alors bon on l'appelle staging mais bon c'est un peu tout c'est le UAT.
Une fois qu'on est sûr que la fiture va bien on essaie de faire en sorte que ça casse pas et que ça s'intègre avec ce qui est déjà existant sur staging.
Donc toi ça veut dire que tu as gardé l'environnement de staging là où apparemment Yann a...
On l'a toujours mais il est quasi inutilisé quoi.
D'accord vous avez une question.
Il me sert juste à savoir que la release sur la prod va bien se passer puisque la release sur staging ça va bien passer quoi.
Ok parce que donc vos environnements fmr sont créés from scratch ils sont recréés à chaque fois ils sont depuis zéro en fait.
Ouais presque depuis zéro en fait.
Aujourd'hui tel qu'on les a implémentés en effet on repart de tous les manifests et déclaratifs Kubernetes également qu'on utilise pour l'environnement de staging.
On prend exactement les mêmes on les récupère on les clone et on les patchs on les override pour justement pour les trucs qui sont vraiment spécifiques aux environnements des éléments de config.
Voilà et on part de staging on part de ce qui tourne en staging.
D'accord d'ailleurs c'est assez drôle pas drôle parce que on sait très bien mais vous avez tout le deux parlé de Kubernetes.
Est-ce que vous avez déjà mis ça en place avant Kubernetes ou est-ce que c'est vraiment cette technologie la façon d'être donc déclaratif qui a permis d'atteindre ou de le faire plus facilement en tout cas ?
Alors moi je tiens tout de suite.
Quand je suis arrivé il y avait déjà ce concept là chez Virtuo mais comment dire Virtuo à l'époque ça fonctionnait sur Heroku qui avait ce concept de review apps pour des applications qui sont plutôt frontales quand t'as pas de database c'est un peu plus facile.
Mais bon pour l'ensemble d'une microservice ils en avaient besoin du coup ils avaient monté quelque chose à partir d'une instance C2 et d'un docker compose.
Mais du coup les configurations de comment tu exécutes ton soft, comment tu le configures étaient drastically différentes entre cet environnement là et finalement ce qui allait être vraiment déployé pour la prod.
Et l'entre-deux ce qui nous a c'est de passer sur cube ça nous a pour nous ça a été une évidence comme quoi ça allait simplifier tout.
Parce que justement les paradigmes que Kubernetes amène avec lui tout ce qui est deployment state to set et autre pour nous ça nous simplifie grandement la déclaration de nos services de notre plateforme.
Et donc après en effet tout ça ça simplifie vachement en mode la prod c'est déjà un dérivé de la prod et nos environnements fmr sont des dérivés de staging.
Et tout ça ça nous a permis vraiment de découper un peu mieux faire en sorte que les applications soient plus portables et plein de choses quoi.
En fait notre première étape c'était bouger sur cube.
Et ça a pris combien de temps en peu près si jamais on parle de la transition on est un peu en dehors du sujet mais juste ça peut intéresser des personnes qui vont passer de héros-coups à Kubernetes par exemple.
Bouger sur cube alors on a commencé le projet de l'année dernière on a vraiment pu commencer à bosser dessus un confinement au mois de mars.
Jusqu'à juillet c'était plutôt de mon côté c'est à dire savoir quel cube manager on a utilisé j'ai qu'à eux vers ce cas et sur ce d'autre.
Et une fois qu'on va dire la base infrastructure vraiment les fondations étaient en place bouger les applis ça a été assez rapide parce que quand tu pars de héros-coups tu as déjà un peu ces paradigmes de 12 factor app d'application bien buildé.
Qui sont pensés pour pouvoir se faire ce chose là donc après la transition elle s'est faite très vite le temps d'écrire les manifeste de faire en sorte que tes URL pointe au bon endroit et en un mois c'était fini quoi.
Et toi Yann ça a été une évidence parce que Cubansist on a un peu parlé en disant que tu aurais aimé peut-être avant faire ces...
J'aurais aimé avant et c'est vrai que avant je me disais toujours ça va être une galère de dingue en fait je pense que si on reprend Youscribe ça aurait été une galère de dingue mais rien que aussi dans la définition de tous les services qu'il y avait.
Et puis parce que la manière de... si on n'est pas en déclaratif je pense que ça devient hyper compliqué de gérer ça alors que là il y a plusieurs choses qui rendent en compte qu'il y a 12 factor app c'est-à-dire que si on part sur cette base là évidemment déjà tout est configurable donc c'est beaucoup plus simple.
Et puis ensuite il y a le fait de parler, de partir sur du déclaratif où oui en effet on se dit bon bah c'est très simple c'est juste cette variable à changer.
On me dit d'un customize il y a de la partie juste héritage récupérer des trucs changer quelques paramètres.
Donc en fait quand je lui ai voulu m'immettre j'ai tous les outils et tout ce qu'il faut pour le faire et ça va être rapide quoi. Alors qu'au part avant je me disais toujours ah ouais ça va être une galère.
Exactement ça. C'est pour ça que justement nous notre préroquis c'était de se dire si on veut uniformiser les usages et moins s'embêter avec ce qui existait qui était à base de deux cas composants on se dit bah cube c'est le chêneau manquant quoi.
Donc faut qu'on fasse ça d'abord quoi.
Et donc là on a parlé un peu de pourquoi vous l'avez mis en place, comment vous l'avez mis en place. Est-ce que vous y avez vu un intérêt... pas forcément que technique potentiellement vous avez pu peut-être lever des bugs je sais pas des choses comme ça.
Est-ce que vous y avez vu aussi d'autres intérêts. T'avais dit Yann que c'était fait pour les stakeholders est-ce que tu as vu un changement dans le dans la manière de discuter avec les stakeholders.
Par rapport à deux expériences que là tu as dit.
Après nous on est vraiment une toute petite boîte on est des fins de la proximité PO Dev elle est hyper forte. Donc c'était plus c'était plus d'un point de vue de nous notre point de vue c'était un peu bon bah ok là maintenant en fait je peux sortir ce que je viens de développer de ma tête.
Parce que je sais que ça va être testé plutôt dans deux ou trois jours pour m'attaquer sur autre chose et je vais pas être interrompu et on va pas refaire des repassages machin etc.
Donc c'était un peu le côté ou même si je suis pour des cycles de développement très court avec des feedbacks loop très courtes bah quand elles sont obligées d'être longs ça permettait en tout cas d'être plus tranquille d'esprit.
Du côté des stakeholders la PO elle va bien comprendre la séparation par feature quelqu'un d'autre non c'est à dire qu'il va pas forcément comprendre ok j'ai trois environnements différents à tester à regarder donc là c'est un peu bizarre donc vous mieux quand même c'est vraiment plus la destination du PO pour le coup que d'autres stakeholders mais.
Si il y a une feature qui les intéresse particulièrement bah ils peuvent comme ça la prévisualiser et puis un peu participer quoi.
Et ça c'était une habitude ou pas parce que de la PO est-ce qu'elle avait déjà eu ça avant non pas du tout.
Parce que oui enfin je pense que tout le monde qui écoute c'est pas quelque chose d'extrêmement courant d'avoir vraiment des environnements.
FMR à chaque fois vous utilisez d'ailleurs quelle plateforme pour donner après ces environnements FMR comment les stakeholders y accèdent.
Ça va être quoi le l'outil vous utilisez je sais que sur GitLab il y a les reviews URL justement ça va être ou est-ce que vous utilisez autre chose.
Ça va être quoi technologiquement la façon de après vous communiquez ça.
Bon à nous on va dire que enfin grosso modo vu qu'on part des URL de prod la différence c'est que au lieu que tu as un mandelet un point prod un point le nom de ta feature.
Ou un ID Gira et grosso modo après nous c'est une appui le client d'un point de vue logiciel c'est une appli mobile.
Donc après les appui mobile chez nous les sont développés pour commander tu dis je veux tester sur un environnement tu entre un endpoint.
Un certain pattern d'URL et après l'application elle se débrouille elle sait que POSPOUF elle va chercher à tel endroit.
D'accord donc il y a forcément eu une partie développement vous vous rendez cas de votre côté sur la partie mobile et donc avec les équipes mobile.
Il y a une intégration.
Nous comme c'est du web c'était beaucoup plus simple c'est une URL qui reprend le nom de la feature.
Après la différence c'est que c'est nous dev qui allons balancer l'URL à la paix ou une entité c'est ça c'est là.
Si on ne valait encore plus un d'automatisation je ferais un message dans cela qui dirait un boom il y a ça que tu peux review.
Et nous à ce niveau là on a vu un truc qu'on a.
Je sais pas moi j'ai l'impression que c'est pas très très mis en avant ou très très utilisé c'est qu'en fait Github a une fonction de notion de deployment.
Que tu peux attacher à ton ripot et à ton projet et justement ça c'est exploité par Eroku et on s'est dit bah tiens c'est pas bête parce que au final c'est une API.
Elle fait rien il n'y a aucune action c'est juste de la méthode attaque tu rajoutes et nous on s'est dit comment ça qu'on allait aller essayer d'exploiter cette API parce qu'on utilise Github.
Et ce qui se passe c'est que du coup sur la page de ton projet maintenant c'est sur la droite t'as la release machin et avant de aller à une section deployment et t'as toutes les URL déjà préfaites en disant ok ton projet il a été buildé et il y a des URL de deployment disponibles là.
Sur la droite c'est parce que t'as mis le plug-in c'est toujours en haut.
Ah bon ah oui pardon mais bref c'est visible c'est accessible depuis la homepage du project d'un repository.
C'est ça que je veux dire donc tu peux pas trop le louper tu sais si tu sais que c'est toujours à peu près texte intrigue parce que tu es obligé d'aller sur Github qui est un outil à la base plutôt orienté pour les tech mais.
Mais il y a ce genre de choses aussi pour des URL mais sinon on fait comme toi on c'est là tiens voilà lui et elle.
Et est-ce que vous avez relevé d'autres choses enfin des résolutions techniques parce que vous avez mis en place ces environnements là.
Enfin si on reprend donc le podcast de la semaine dernière avec Arnaud on a vu que mettre en place des environnements là pour le coup d'intégration donc des tests rapides dans le cours de cours de développement ça nous a permis en fait de voir énormément de problèmes remontés en fait des choses qu'on ne s'est pas perçu.
Est-ce que vous ça a eu à peu près le même effet de faire ces environnements plus long terme qui ne servent pas que au test mais qui sont pour un test humain en fait ces environnements femaires.
Bon moins ou est franchement nous ouais plutôt enfin là on est encore c'est hors liste c'est-à-dire que ces environnements femaires sur cube on vient d'arriver depuis janvier.
Mais déjà dans l'usage par rapport à ce qu'il y avait avant sur cette docker sur cette machine avec un docker composé des scripts shell un peu main basé sur plein de conventions là on est beaucoup plus explicite et ça nous a permis de déjà visualiser et d'exprimer plein de loups que.
On a du mal à exprimer avant quoi c'est à dire que là on voyait explicitement ok là il y a du code pas du pliqué ça c'est pas portable ça c'est ça marche pas et donc même si à la fin.
L'environnement femaire est d'abord à destination du PO pour qu'il puisse avoir un environnement isolé complet sur sa feature mineur il nous sert également à nous parce que.
Et grâce au fait que Kubernetes c'est déclaratif et on a essayé de faire en sorte que les manifest des applications soient dans les ripos des applications très proches du code donc en fait le développeur il a vraiment.
La notion est même pour lui c'est beaucoup plus clair de savoir ok une fois que j'ai mon conteneur voilà comment ça marche quoi voilà comment ça tourne et donc ça c'était très très cool.
Ouais mais c'est comme on a discuté un peu tout à l'heure ce qui va se rendre compte en fait quand on va vouloir mettre son application comme ça c'est que tout ce qui va être la gestion des services externes tout d'un coup devient en fait un.
Un enjeu un souci ou quelque chose comme ça mais c'est à dire que il faut pas réutiliser les comptes de prode qu'on a créé sur des services externes et surtout on va se dire bah une range devrait recréer en fait les mêmes configs que j'ai pour la prode pour chacun de mes environnements la plupart du temps ça a été fait à la main en mode cliquique.
Sur des hautes zéro mais sur des mailgun sur des plein de trucs de services comme ça et donc ça pose la question de mais en fait pourquoi cette connaissance de la configuration de mes services externes elle est que dans ma tête et que ou elle est dans une doc si on a fait au mieux quoi et qu'elle n'est pas elle n'est pas.
Déclaré comme on déclare le reste des configs de nos app et comment tu as vu tu as réussi à résoudre ça je dis ça en grandit de connaissant la réponse mais.
Moi j'ai commencé par la première chose que je me suis c'est mais en fait ça devrait être à côté de mes déclarations de mes app donc ça devrait être dans cube et ça devrait être des des fichiers qui sont en destination de cube donc d'un opérateur et j'ai notamment développé un opérateur par exemple pour mailgun pour configurer automatiquement.
L'environnement de Staging et l'environnement de la PR pour mailgun et notamment parce que j'avais une notion de webbook.
Dans mailgun où je vais les récupérer les retours des mails et en fait c'est une feature dont j'ai besoin aussi pour mes paires quoi et qu'on peut pas mettre la Staging qu'on peut mettre à la prod donc il faut isoler ça.
C'est comme ça que j'ai résolu le truc maintenant ça c'est au mieux c'est à dire quand les services ont une API si on prend un Slack en tout cas à l'époque où je m'y intéressais beaucoup Slack n'avait pas d'API pour créer des apps par exemple.
Donc à partir de ce moment là on est on est dans le côté un peu relou des environnements de test ephemères c'est à dire que va falloir bricoler les choses pour faire en sorte que ça fonctionne pour que le Slack fonctionne sur tous les ans de feature.
Là c'est bien on arrive on commence à arriver aux limitations alors là pour une fois je vais donner mon avis là dedans et parce que des gens m'ont suivi sur Twitter et mon où j'ai donné un peu mon opinion donc on le voit bien les environnements ephemères sont vraiment très cool.
Parce qu'ils répondent à des problèmes au niveau des POU en tout cas ils améliorent les choses ils vont être très similaires à ce dont on parlait la semaine dernière avec les environnements de test au final c'est des environnements de test pas totalement automatisé où il y a une part manuelle à faire.
Donc en fait ils répondent à cette dernière partie qui est comment je fais tester un utilisateur humain une fonctionnalité.
Moi mon problème que j'ai avec ces environnements ephemères c'est que c'est un peu ce que tu disais là il y a toujours.
Il y a toujours une dernière partie chiant il y a toujours une dernière partie qui rentre pas exactement dedans et qui fait que l'environnement de test n'est jamais la prod.
Déjà souvent il n'a pas les données de prod il n'a pas la charge il n'a pas beaucoup de choses qui n'a pas et dans lequel on peut pas tester.
Ce qui fait que j'ai toujours un petit problème l'un de dans de de de qu'est ce que ça apporte vraiment.
Et donc moi personnellement en tout cas si jamais je ce que je prône c'est de me dire et si on arrêtait donc ce principe d'environnement de test on laissait pour les environnements d'intégration
ce qui sont très bien on a des tests automatisés qu'on fait tourner une fois par jour et qui nous lait lièvre beaucoup lièvre.
Mais cette deuxième partie après d'avoir vraiment des environnements tout intégrés c'est à dire vraiment de bout en bout nous quand on en parlait la semaine dernière
on parlait juste de une partie de l'infrastructure donc on testait notre infrastructure par bout par parti.
On testait vraiment un usage extrêmement précis qui nous permettait d'avoir des tests d'intégration un peu plus simples qu'un test de bout en bout.
En plus le problème que j'ai quand on fait des environnements fmr c'est que donc qui sont complets c'est des environnements qui sont de bout en bout et donc en termes de prix de pricing quand on est surtout une petite boîte
on se retrouve alors il suffit d'avoir trois PR et ça y est on a fait 4 dans le nombre d'infrastructures qu'on a.
Pour une différence en plus pas gigantesque quand on a une petite startup on a deux backend en prod pas beaucoup plus que ça
là dans le seuls coup on se retrouve à avoir on a multiplié le nombre de backend qu'on a dû installer et en plus qui sont gérés par des êtres humains.
Donc après on peut faire des hacks en disant oui ok moi la nuit je sais qu'il y a personne qui s'y connecte donc je vais les enlever.
Ça rajoute en fait du bruit et des composants à devoir gérer etc.
Personnellement je pense que la chose qu'il faut sans doute changer c'est de passer vers quelque chose d'autre qui sent plutôt des.
Du feature flagging donc dans le sens où il n'y a que la prod qui ressemble à la prod et donc on envoie son code en prod avec un système de flag qui correspond un peu en fait à cette notion de.
De endpoint dont tu parlais un peu Xavier qui est dans l'application on active ou pas telle fonctionnalité sauf que là au lieu d'avoir une notion d'infra de savoir où est ce qu'on va on a une notion de.
Functionnalité on va dire au PO bon bah tiens tu as une version de dev une version de testeur et tu vas accéder à telle ou telle fonctionnalité qui est déjà déployé en prod.
Est ce que ça c'est quelque chose de fin je sais que y'en a un.
Moi en fait c'est pas que il y a d'autres choses encore qui viennent après le feature flagging et il y a beaucoup de soucis notamment dans la mise en place donc.
C'est à dire qu'en fait c'est je pense que chaque solution à ses contraintes et ses qualités.
Pour moi c'est plus que dans le feature flagging ça veut dire qu'il y a du code qui vient de rejoindre la master et que ce code là en fait peut-être qu'il ne devrait pas du tout y être.
Et donc il y a la notion de devoir enlever dans du code prod quelque chose qui est potentiellement été mis et qui en fait était pas valide d'un point de vue du PO.
Donc ça c'est j'ai pas assez d'expérience sur le feature flagging mais c'est vrai que j'y vois d'autres soucis quoi.
Voilà donc c'est en plus ou moins après c'est une question de tête d'habitude ou de opportunité technique c'est à dire que là à cube les 12 factor app donnaient une opportunité technique.
Et donc je les saisis alors que le feature flagging c'était un apprentissage certainement des pratiques et que c'était pas encore un assez gros problème pour que je fasse un réapprentissage de pratique.
Tu l'as dit un peu c'est que tu aimes bien les cycles courts alors actuellement ça passe encore.
Peut-être que quand on arrive à des cycles de PR qui sont vraiment très longues qui arrivent pour ça aussi que j'ai demandé un peu le temps que vous mettez.
Et bien pour le coup avoir des PR comme ça qui sont stock par des par des PO qui font très bien leur boulot mais c'est juste que ça peut prendre du temps à tester avec des cas.
Des fois même peut-être vouloir le montrer à des clients en disant parce que des fois le PO n'est que l'intermédiaire avec d'autres clients voire le valider etc.
Et on se retrouve à avoir des PR qui dure qui dure avec en fait une célérité dans la mise en production qui est très compliqué.
Et donc en tout cas on va se dire est-ce qu'on fait du cherry pick de tous les bugs qu'on a fait entre la PR et ça.
On peut potentiellement avoir un problème avec des PR qui se retrouvent avec des rebays complètement affreux à faire dans le temps.
Et c'est là où le feature flagging fait qu'on est un peu plus confiant à mettre en prod parce qu'on met en place des fonctionnalités qui ne sont pas utilisées.
Et même d'ailleurs on les teste instantanément on teste une changée et une montée en charge.
Ça permet aussi de faire de l'AB testing c'est des choses que en fait avec ces environnements de EFMR il n'y a pas d'AB testing possible.
On a quelque chose où on peut le faire à la limite mais ça devient compliqué parce qu'on ne touche même pas aux mêmes données.
On peut avoir des environnements EFMR qui touchent aux mêmes données.
Ça serait possible remarque. Et on a ce petit problème là.
Et le feature flagging en plus maintenant on commence à avoir des outils.
Alors il y a beaucoup de détracteurs mais on commence à avoir des outils comme East Iow ou tous les outils de service niche.
Voilà qui peuvent permettre de manipuler le feature flagging et de se dire non mais je ne déploie en fait on se retrouve à avoir quasiment un environnement EFMR.
Et puis on a une application sur pour ce micro service là, pour ce service là, on déploie un environnement EFMR de telle PR.
Et si jamais je mets le Header Toto PR Gira 36 et bien je me retrouve à utiliser les composants de Toto Gira 36.
Voilà je ne sais pas ce que...
Moi je vais reprendre ce qu'a dit Yann et c'est très juste c'est une histoire d'opportunité.
Et en plus aussi pour appuyer un autre truc qu'on dit assez souvent ici c'est une histoire aussi de maturité.
C'est à dire qu'on apprend tous des choses et alors d'aujourd'hui pour nous pour faire en sorte que les développeurs et les PO puissent être assez autonomes c'était ça.
Et ça nous a permis de le faire, on a trouvé un gain et maintenant on arrive à se dire on peut se dégager du temps pour passer à la learning curve de l'étape d'après.
Donc tout ce que tu mentionnes en effet feature flagging c'est un truc qui traîne dans nos têtes depuis un certain temps.
Du service mesh également ça fait un truc qui traîne dans un certain temps.
Et c'est clairement les next steps quoi c'est clairement les deux pistes et les deux voix qu'on voudrait envisager et qu'on va regarder très près au cours de cette année ou des années qui vivent.
Mais tu vois c'est vraiment une histoire de maturité.
Ok j'ai réussi à faire cette step pour l'instant elle est satisfaisante, elle amène ses problèmes comme tu viens de le dire, elle amène aussi ses solutions.
C'est un compromis maintenant une fois qu'on a ça qu'on sait comment ça marche que ça nous a déjà permis d'identifier pourquoi une appli elle n'était pas automatisable.
Comme tu le disais tous ces services externes qui sont en clic-clique tu fais ah oui je ne m'en souviens plus de ça.
Et bien tout ça c'est ça et c'est une next step.
Donc nous on est fait clairement l'une des next steps parce qu'on a tous les problèmes que tu mentionnes bah ce sera misé sur le feature flagging et le service mesh.
Moi je dirais qu'au niveau de là où on est pour l'instant pour la boîte il n'y a pas de ça serait peut-être plus complexe finalement qu'autre chose.
Mais je trouve ça intéressant parce que c'est un autre challenge et ça pose d'autres questions mais ça vous donne d'autres opportunités.
Et en fait il faut se demander c'est déjà est-ce que le métier a besoin de ces opportunités là.
Pour l'instant nous on n'a pas forcément besoin mais j'imagine que par rapport aux expériences précédentes que j'ai eu que évidemment c'était nécessaire d'avoir des bit testing, du feature flagging aurait pu être intéressant.
Donc voilà après il faut bien le faire c'est à dire que moi je déjà connu aussi dans mon passé de dev, des gens qui ont fait une feature mais elle n'est pas en prod on va mettre en prod après Noël en e-commerce et puis en fait bah elle était dans, elle était en fait d'une manière ou d'une autre en production c'est à dire qu'elle n'était peut-être pas visible pour les utilisateurs mais elle avait quand même un impact sur les données quoi.
Et donc elle avait créé des conneries donc voilà c'est les trucs comme ça où tu te dis bah en fait ça demande d'une certaine maîtrise donc voilà.
C'est sûr et c'est pour ça d'ailleurs que sans doute basculer en feature flagg en milieu de développement dans une application qui est donnée quasiment legacy.
Enfin si jamais vous avez une expérience là dessus d'ailleurs les auditeurs n'hésitez pas à venir alors là faire.
Ça sera peut-être d'ailleurs la prochaine évolution après celui sur les environnements de test, d'intégration, les environnements l'ifmr deuxième des gens qui pourraient venir nous donner leur expérience avec du feature flagging.
J'adorerais ça.
Tercement je le prône j'ai jamais fait et je l'avoue complètement et parce que j'ai pas parce que je ne voulais pas mais parce que j'ai jamais réussi.
Il faut pas oublier que je suis indépendant la plupart du temps maintenant et que bah je ne peux pas mettre ça en place.
Il faut trouver le cas.
Il faut trouver le cas mais il y a plein de choses je pense qu'on en parlera dans un épisode dédié au feature flagging.
Il y a plein de choses normalement en lien avec les PO pour en avoir un peu de discuter à certains des choses qui même n'imagine même pas que ce soit possible à faire.
Je vais donner un exemple que j'ai dit pas très longtemps.
En imaginant qu'on teste une fonctionnalité donc dans un environnement pour spécifiquement un événement particulier.
On veut que à midi le jour X, il y ait telle nouvelle fonctionnalité parce que ça change complètement le site qui devient spéciale Black Ferry.
Black Ferry d'ailleurs.
Voilà on a notre test et bah en fait on se retrouve à mettre en production pile poil au moment où en fait c'était le plus urgent en fait.
Et donc potentiellement on pète tout alors même que c'était le truc urgent alors qu'avec du feature flagging on peut très bien se mettre à genre déployer dans les jours avant le feature Black Friday quand c'est à peu près calme.
Les gens peuvent tester et le jour du Black Friday au lieu d'avoir besoin d'avoir un développeur qui est là à minuit pour faire le déploiement et bah en fait on peut avoir directement les PO, les stakeholders qui sont sensibles et c'est eux qui font la mise en production en fait.
C'est eux qui décident et bien voilà pour 100% de mes utilisateurs je passe en mode Black Friday et en fait il y a une responsabilisation que je trouve assez sympa des PO potentiellement.
Alors petite note nous c'est déjà les PO qui réalisent parce qu'on avait on a bah en fait quand je suis arrivé c'était déjà un peu le câble mais on a continué à miser dessus en fait on a un petit bout de Slack qui est accompagné et on a fait un petit matching forcément comme beaucoup de boîte alors après c'est mal ou c'est bien hein.
Mais entre TPR les id détiqué et autres et grâce à ça les PO sont vraiment autonomes sur Slack ils sont là on me tient liste moi c'est réalisent ok tous ces tickets là tous ces microseries sont impactés vas-y déploie et c'est eux qui le font.
Ok est-ce qu'ils peuvent rollback ?
En fait en fait quand on est responsable on est responsable du rollback c'est-à-dire que là en fait c'est-à-dire que si jamais le PO décide de mettre en place une fonctionnalité et que ça ne marche pas et bah en fait il est à poil.
Oui un effet non alors on sait rollback maintenant en effet je pense que tu sais après c'est des dogmes il y en a qui vont te dire il n'y a que la fiche en avant qui compte t'as un problème tu le fixes.
Oui mais ça veut dire qu'il n'est pas autonome en fait en fait il a l'illusion de l'autonomie et je ne suis pas très très fan de l'illusion.
La raison c'est un point qui nous manque.
Si ça ne fonctionne pas c'est quand même toi le...
Alors que là potentiellement en fait avec le feature flagging parce que ça a été testé parce qu'on l'a déjà mis en place parce qu'on a testé ça deux minutes hop ça a l'air d'être passé hop on remet on repart et voilà.
Bon encore un autre après ça fait une matrice de compatibilité à tester les feature flagging qui des fois peut être sympa mais en effet.
Ça apporte des problèmes à 100% même juste des modèles de données ou des choses comme ça donc ça veut dire gérer ça enfin c'est un enfer en soi mais qui je trouve apporte pas mal de choses aussi bien à l'infra en termes de tests et aussi en fait au métier.
Et ce qui est le fait le plus important on n'oublie pas on fait pas de l'infra pour l'infra on fait de l'infra pour le métier et donc c'est ce que Yann a dit je te cite mais c'est voilà pour un moment votre métier on n'a pas besoin.
C'est vraiment ça et il y a une sorte de charge et des chels et de taille voilà si jamais demain mettre en place une nouvelle fonctionnalité divise par deux les pertes mais parce que c'est sur un environnement de test où il y a deux PO qui s'y connecte dans l'année vous avez pas vu ces problèmes de perte.
Je sais pas si vous avez quelque chose d'autre à rajouter dessus quelque chose qui n'a pas parlé quelque chose qui vous est arrivé qui qui est quelque chose de particulier une expérience.
Quand tu parles de charge aussi ça c'est un topic à sa part entière ça s'appelle qu'est ce que tu fais des tests de monter en charge ou pas.
Nous je crois pas qu'on en est mais c'est aussi un topic qu'on voudrait aborder cette année et pour le coup pour l'instant l'idée initiale c'est de se dire qu'on testait sur cette fameuse environnement de staging.
Une fois que la feature est complayante on vous intègre et une fois que c'est intégré sur staging on teste en charge à voir mais c'est vrai que c'est des sujets intéressants.
Il y en a qui font ça systématiquement il y en a ça reste un doux rêve ça dépend.
Non non je ne pense pas spécialement de tout cas raconter ce qui me choquait quand je fais le truc c'est que je me suis rendu compte que certains services qu'on utilise n'ont pas d'appelis pour créer et configurer ces services-là alors que c'est les services externes et je crois que c'est en fait assez délirant que ce soit encore le cas et qu'on ait encore des services externes dont la configue est dans notre tête et c'est tout quoi.
Et c'est sans doute peut-être la preuve que peu de gens font ces environnements là là dessus c'est la preuve qu'il n'y a pas de temps d'attendre que ça et donc c'est peut-être aussi le but de ce truc là d'utiliser votre envie.
Si si je peux te citer un prestataire ou moi qui m'a fait un peu je vais pas donner son nom mais juste le cas d'usage voilà il y en a on en a utilisé un finalement.
Il y en a contesté juste sur ce qu'il était capable de produire un deuxième on a dit super c'est celui là qu'on veut vas-y on y va et on lui a donné tout ce qu'il faut de notre point de vue comme des accès à des bouquettes et autres pour avoir un environnement et puis il a dit ouais pas de problème l'environnement sera près dans deux semaines.
Comment ça c'est à dire que tu vas faire la requête dans deux semaines non non ils sont déjà en train de le construire.
D'accord.
Avec complètement la célérité de déplamant elle est pas du tout la même en fonction des prestataires et c'est vrai que c'est quelque chose qui commence à arriver et je pense que si jamais.
Il y a des parties de l'écosystème 6 mètres ce qui fait que d'autres prestataires vont avoir besoin des prestataires vont le faire qui vont que ça va donner des envies à d'autres extra il y a vraiment une pollinisation en fait de l'écosystème qui viendra sans doute avec des sociétés comme les votes qui les font créer des opérateurs.
Ton opérateur il y a il est sur github si jamais vous l'avez utilisé voilà que.
Il est référencé et sur mon github il est référencé aussi dans les référencement d'opérateurs qui se trouvent sur internet.
C'est un opérateur quelque chose comme ça.
Donc voilà n'hésitez pas n'hésitez pas je pense qu'on en fera un jour quelque chose sur les opérateurs ça fait longtemps même peut-être déjà fait.
Je sais pas en tout cas je dis comme ça pour citer il y a aussi un meet up sur la scène parisienne qui s'appelle SRE Paris et il y en a le dernier c'était jeudi dernier et il y a juste un quelqu'un qui a fait un gros retour d'expérience sur les opérateurs et en gros son moto à la fin c'était c'est tellement bien c'est tellement facile qu'il n'y a pas de raison que vous en fassiez pas.
Je précise c'est après un fois que je connais Rango donc c'est pour dire à quel point c'est simple et facile.
C'est pas le plus simple potentiellement il aurait pu avoir plus simple mais en tout cas ça marche et c'est plutôt pas mal et c'est puissant.
Merci beaucoup à tous les deux d'ailleurs face ce retour c'est bien ça vient en complément de la semaine dernière et encore d'autres on peut espérer.
C'était notre premier podcast avec des masques donc désolé pour le son si il y a quelque chose d'un peu étouffé de avoir l'habitude.
Maintenant vous savez on a des masques en ce moment donc n'hésitez pas à repartager à venir nous envoyer enfin envoyez nous un message si vous voulez participer si vous avez un sujet.
On est vraiment super ouvert et ça serait avec plaisir on les fait aussi bien sûr en remote à l'heure actuelle on n'est pas forcément obligé d'être en physique c'était juste l'occasion de le faire mais voilà.
Est-ce que tu veux mentionner que il y a une communauté discord ?
Exactement il y a un discord j'oublie des fois de le dire donc rejoignez le discord on fait les enregistrements en ligne sont fait dessus en direct donc même vous pouvez participer en posant des questions la solution est fait offline à l'ancienne.
Et voilà merci à tous d'avoir écouté et puis bonne journée à la prochaine.
Merci beaucoup.