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 continue.
Face à des...
Ça, oui, naturellement ensemble, ça donne des résultats contre...
DevOps.
L'objectif individuel, ça s'atteint.
Alors que d'une ambition, ça se partage.
Bonjour à tous et à toutes.
Bienvenue dans un nouveau numéro de DevOps.
Aujourd'hui, nous allons parler de feature flag.
Si vous ne savez pas ce que c'est, c'est le bon endroit.
Si vous savez, je suis sûr que vous allez apprendre plein de choses.
Avec moi, j'ai deux nouvelles personnes qui s'y connaissent très bien sur le sujet.
J'ai Thomas.
Salut.
Et on en voit aussi Henrik.
Bonjour à tous.
Henrik, vas-y, je te laisse te présenter.
Je m'appelle Henrik Hexel.
Je travaille actuellement chez Dina Tras,
en tant que cloud native advocate.
Mais sujet de...
Vauré, on va dire, ou de prédélection.
Ça va être tout ce qui est Kubernetes,
tout ce qui est Open Observatory.
Et puis, en fait, je suis ce projet
qui a été initié par de mes collègues,
chez Dina Tras, qui s'appelle Open Feature.
Et donc, je suis...
Ce qui explique ma présence, aujourd'hui, à ce podcast.
Mais si on doit rentrer dans le détail
de tout ce qui se passe sur la partie telemétrie et observaté,
je serai ravi de partager plein de choses.
Et juste pour faire une petite intro et promotion,
j'ai lancé il y a un an de cela,
une chaîne qui permet d'aider la communauté
à se rentrer dans les sujets d'Open Observatory.
Donc, notamment, cette chaîne YouTube s'appelle
Is It Observable ?
Et en fait, je fournis des tutos,
que ce soit sur comment on collecte des logs,
comment créer de la telemétrie, comment...
Tout ce qui est tuto, de manière générale,
sur l'observaté.
Donc, partie promo,
pour ceux qui ne le connaissent pas, cette chaîne.
Super, je le mettrai en description du podcast.
Vous aurez le lien, ce sera directement là.
Et Thomas ?
Oui, bonjour.
Moi, c'est Thomas Pognan, je suis TechLitch,
chez Adevinta, donc Adevinta, c'est la maison mère de Le Bon Coin.
Et je travaille sur différents sujets,
notamment sur la bordération chez eux.
Et j'ai un site project à côté de ça,
qui s'appelle GoFlector Flag, qui est une librairie de Flag
pour Go.
Et je fais aussi amener à contribuer un petit peu
à OpenFlector depuis quelques temps.
Super.
Vous me connaissez ceux qui écoutent le podcast,
donc pas de besoins trop me présenter,
mais je suis indépendant,
je travaille surtout sur le domaine du DevOps,
et beaucoup sur Kubernetes.
Pour le coup, ça va être assez bien,
parce que je vais être un peu vraiment le rôle du newbie lundan.
Je connais bien le monde des future flags,
c'est-à-dire ce qu'on peut faire, ce qu'on pourrait en tirer,
mais j'ai jamais eu malheureusement l'occasion de l'implémenter.
Ça dépend, bien sûr, des clients à chaque fois que je vais avoir.
Et pour l'instant, c'est chou blanc.
Donc c'est bien, je vais être vraiment la personne,
la personne la plus... la moins experte dans ce domaine-là.
Donc ça fait du bien.
Et donc, d'abord, je voudrais vous demander, justement,
comment vous allez définir le future flagging,
et peut-être votre première expérience avec,
comment vous l'avez appris, vu et utilisé.
Thomas, peut-être ?
Euh...
C'est un...
Définir, c'est toujours compliqué,
mais pour moi, l'idée du future flag,
c'est surtout de pouvoir agir sur...
son environnement de production, sans avoir à faire de déploiements,
donc de pouvoir avoir des modifications de comportement
depuis l'extérieur.
Et avec surtout la volonté de découpler un déploiement d'une release,
c'est-à-dire que le déploiement s'est poussé du code,
release, c'est mettre en place une...
mettre à disposition une nouvelle fonctionnalité.
Et moi, j'ai commencé à utiliser les future flags
dans une... dans la...
ma boîte précédente qui s'appelle Front,
qui est une scale-up.
Et on était des gros utilisateurs de launch d'Arcly,
et le use case de Baz,
qui était vraiment celui qu'on faisait le plus,
c'est que tout ce qu'on déployait était sous future flag,
et c'était au product manager d'ouvrir les flags
au moment des releases.
Donc c'était les...
On découplait vraiment la partie déploiement
qui était faite par les ingénieurs,
de la partie release qui, elle, était faite par les product managers.
Alors moi, j'ai...
Mon premier expérience, ça a été de future flag,
c'était en tant qu'utilisateur.
C'est-à-dire, on est...
Quand on gère des problématiques
au cours de clients, on va dire,
on se dit, tiens, il y a telle fonctionnalité,
et on découvre que certaines fonctionnalités
sont, du moins, sur la plateforme,
sur laquelle je travaille,
sous future flag.
Et puis, du coup, de découvrir le fait
qu'on avait une plateforme en termes
pour gérer l'activation de future
pour certains clients.
Et donc, la mise en œuvre de cette plateforme,
ça nécessite quand même
un certain travail en préalable.
Et donc, je suis toujours dit,
tiens, c'est génial cette technologie
de pouvoir activer des fonctionnalités
aux besgros, aux fonctionnalités utilisateurs,
à fonction de sa géographie,
de son âge, de plein de différentes critères.
Mais la gestion et la mise en œuvre,
elle peut être très lourde
et très compliquée à terme.
Et donc, c'est la raison,
justement, de ce projet qui a été initié,
pour pouvoir se dire comment on pourrait mettre
un standard, en fait,
sur l'industrie
pour éviter, justement,
des devs, des implementations un peu customes
pour arriver
à mettre en œuvre ce type de fonctionnalités
aux mains de nos utilisateurs.
Ok, cool.
Et donc, à quel moment vous allez l'utiliser,
est-ce que c'est compliqué à mettre en place ?
En fait, j'ai fait un podcast la semaine dernière
pour te vous dire. La première chose quand j'en ai parlé,
c'est compliqué. On ne peut pas le mettre en place.
Enfin, voilà, c'est les choses un peu trop
un peu trop blinine, on va dire.
Vous, ça vous a pris du temps,
c'est quelque chose que vous feriez par défaut
ou au bout d'un certain moment ?
Moi, c'est une custom. J'essaye de le mettre.
En fait, plutôt, on le met en place
dans un projet, plus c'est facile pour la suite,
dans l'idée,
dans le sens où
les Fitterflags, c'est avant tout du tooling
et des SDKs
à mettre dans son application.
Une fois que le SDK est là,
configurer des flags et les mettre en place,
c'est quelque chose d'assez
d'assez facile à faire.
Ce qui est le plus compliqué
à mon sens, c'est le cycle
de vie des flags. C'est-à-dire que
le jour où un flag n'est plus utile,
il faut toujours passer par une phase
de nettoyage du code pour éviter d'avoir
des appels à cette librairie de Fitterflags
partout. Et du coup, c'est
c'est aussi une mécanique et une organisation
à avoir au sein de son équipe
et de son projet pour être sûrs
qu'on peut en clean bien après
l'utilisation des flags.
Mais en soi, techniquement,
c'est des ifs.
On ne va pas se mentir, c'est des ifs
qui check si le flag est actifé
ou pas. Quand je dis
activé, on pense
beaucoup aux Fitterflags en True
or False, même si on peut faire plein d'autres choses avec.
Mais c'est
un peu ça le cas
de par défaut à mon sens.
Dans le monde de son Moco, ou sur le aspect
de la gestion, comme tu disais, effectivement
c'est des ifs
qui s'imbriquent. Après, la grosse
problématique, c'est la source de données.
Il y a toujours
un critère qui va dire, tiens, je veux activer
que pour
un certain type de population, ou un certain type
de client, ou un certain type d'environnement.
Et cette
source de données initiales, souvent
au-delà des ifs
et la gestion des Fitterflags, il faut aussi gérer
cette
gestion.
Ce qui peut rendre compliqué,
surtout, on pense
toujours, aujourd'hui, j'ai un environnement
je suis très content avec ma plateforme
et Frémort que j'utilise.
Mais il y a toujours un
et demain, que va-t-il se passer ?
Et souvent, cette question de
et demain, on ne veut pas se la poser
cette question. Parce souvent, quand on a commencé
à mettre un système qui peut être compliqué
à déployer
et à manager, on se pose vraiment la question
de dire, le jour où je vais changer
de l'outil âge ou de plateforme,
je d'y penserai l'aujourd'hui, parce que
ça me fait déjà transpirer.
Et je pense que
que ce soit, d'ailleurs, dans plein
de sujets divers et variés, pas que
sur l'OpenFly, Fitterflag,
sur plein de sujets différents, aujourd'hui,
quand on met en place un outil, on a
souvent retaient peur de se dire,
quand je vais changer d'outil, ça va me coûter
quasiment le même
coût de mes enoeuvres
que quand on a démarré
cette plateforme.
Donc ça, ça peut être un critère
justement de
stickiness, c'est-à-dire que pour un
éditeur, ça peut dire, c'est génial, une fois que je suis
dans la place, je resterai à vie,
parce que c'est trop compliqué à me retirer.
Et je pense qu'aujourd'hui,
avec toute l'évolution de la technologie qu'on a
aujourd'hui, on ne peut plus avoir cette logique
de dire, une fois que je suis dans la place,
on ne me retire plus.
Non, il faut avoir cette souplesse,
cette standardisation
pour faciliter
justement la transition vers
d'autres outils, ou d'autres solutions, ou d'autres
architectures, ou de technologies.
Tu ne voules pas forcément vers quelque chose
maintenant, c'est donc la standardisation,
c'est ça qui va peut-être permettre
ce genre de choses. Alors actuellement, est-ce
qu'il y a un standard de facto qui est utilisé,
je ne sais pas, une libre de facto qui devient
un standard, ou pas du tout,
et qu'est-ce qui peut venir
pour améliorer l'écosystème ?
Alors, à mon sens, il y a plein de solutions
de feature flag qui existent
sur le marché.
Mais jusqu'à présent, chacun
de ces solutions avait
leur propre manière
d'exprimer
entre guillemets le feature flag
en tant que tel.
Et je pense qu'aujourd'hui,
d'avoir la création
de ce projet OpenFeedsure,
et justement d'aller voir tous ces différents
éditeurs qui travaillent dans cet
univers, et de dire,
allons dans le sens de la standardisation,
allons dans le sens du client,
et mettons en place un standard,
ça permettrait
de faciliter la mise en œuvre
et créer une adoption sur le feature flag,
même si aujourd'hui, beaucoup d'organisations
utilisent le feature flag, mais peut-être que
certaines organisations aujourd'hui ne le mettent pas
en œuvre, parce qu'ils voient quelque chose de très
chronophage et très compliqué à mettre en œuvre,
et si peut-être, grâce à ce standard,
ça a peut-être démocratisé le feature flag
dans plein d'organisations,
comme ça dans le domaine bancaire
un peu plus traditionnel,
que dans des start-ups très innovantes.
Thomas, là-dessus.
Aujourd'hui, les solutions de feature flag
elles ont toutes leurs SDK à elles,
en gros.
C'est-à-dire que pour utiliser une solution,
il faut prendre le SDK du vendor
et l'utiliser.
Ce qui aussi empêche
de passer d'un vendor à l'autre,
facilement, et notamment de passer
typiquement de solutions open source
peut-être, comme celle que
moi je fais avec feature flag,
qui est une solution très simple et qui permet
d'avoir une première expérience avec le feature flag,
à une solution type launch bar click
qui coûte des milliers d'euros par mois,
parce qu'on a des millions d'utilisateurs.
Aujourd'hui, faire l'immigration de l'une à l'autre
c'est des choses qui coûtent et qui nécessitent
de repasser dans son appli, changer son SDK,
potentiellement changer tous ces appels
qui vont être différents,
et donc, du coup, se retrouver
dans une situation où ça devient un projet
de changer de solution de feature flag.
Et c'est là où
OpenFuture qui est en train d'arriver
veut résoudre ce problème-là en disant
ayons une première couche qui est commune
à tout le monde, et après, chacun
implément la façon de challenger
les flags de façon différente
et à sa sauce, avec
tout un tas de features associés à ça,
mais
la façon d'avoir son info sur son flag
est commune à tous les vendors
et plutôt que d'être loqué
à un vendor comme on l'expliquait
juste avant.
Enrique, tout à l'heure, t'as dit qu'il y avait
plusieurs façons d'exprimer ça,
enfin, Thomas, en finissant,
ça va être quoi ces façons d'exprimer ?
En fait, qu'est-ce qu'on va avoir comme différence
fondamentale, peut-être, dans la manière
de voir le feature flag ? Et peut-être
le meilleur chose, c'est, enfin, par l'exemple,
qu'est-ce que ça veut dire d'utiliser le feature flag ?
Et qu'est-ce que je vais pouvoir exprimer
comme différence ?
Bah, comme Thomas vient de l'expliquer,
il y a plusieurs choses, donc il y a effectivement
ce besoin de mettre un SDK
dans le code qui va permettre
d'interfacer sur la solution
finale.
Donc ça, c'est un premier biais. Mais après,
sur la manière dont on va activer
un feature flag, on peut le faire
de plein de manières différentes.
Ça peut être, comme j'ai dit,
je peux très bien le dire, bah tiens, j'ai
cette fonctionnalité qui me permet de
compresser
le prix de l'article avec la livraison.
Mais sinon, je suis
un site d'E-commerce
et j'ai fait une fonctionnalité en disant,
bah tiens, j'ai fait une fonctionnalité qui va
peut-être
améliorer mon positionnement à mes ventes
parce que je vais inclure
un prix complètement global
qui va inclure tout pour l'utilisateur.
Mais cette fonctionnalité, je suis pas sûr
si ça va gonfler mes ventes ou pas. Donc,
j'ai envie de l'activer au besoin
sur une population éterminée. Donc, par exemple,
je dis, bah tiens, je vais pas prendre trop
de risques, je vais identifier
une région dans le monde et je vais
activer cette fonctionnalité que sur cette
région, par exemple. Ou peut-être,
je vais dire, bah tiens, je vais plutôt l'activer
sur mes clients qui ont une tranche
d'âge particulière. Donc,
d'avoir le critère qui va décider
quand est-ce que j'ai envie de mettre en
œuvre, mettre à disposition
cette fonctionnalité à un certain type
utilisateur, elle va forcément varier en fonction
du besoin. Donc, on peut très bien avoir,
tiens, j'ai une interface et je me dis
tiens, j'active ça pour telle client.
Donc là, je suis la référence de client.
Mais on peut avoir des règles beaucoup plus
complexes et plus
sophistiquées pour activer
au besoin des fonctionnalités
dans des zones, comme je dis, dans
des zones de graphie, par exemple.
Il y a ce genre de besoin et il y a aussi
d'autres fonctionnalités liées au
feature flag qui sont super intéressantes.
Moi, celle que j'adore,
c'est le kill switch. C'est-à-dire,
je viens de déployer une feature à
1% de mes utilisateurs pour le tester
ou 10%
pour tester ma feature et je me rends compte tout
de suite qu'il y a un souci avec ça.
Je peux directement remettre,
désactiver mon flag et être sûr que je
reviens sur l'ancien mode
et donc me retrouver avec
un rollback, on va
dire, instantané, sans avoir
à redéployer du code
et donc potentiellement
avoir le temps du déploiement. Il y a
des vendeurs qui font
juste du on-off,
donc du true-false.
C'est moins en moins le cas.
Maintenant, la plupart
des vendeurs qui le proposent
c'est être capable
de configurer du texte,
des objets de zone,
ce genre de choses dans les flags
et donc aller plus loin, ça peut même
être... les flags deviennent
des objets de configuration en soi.
On peut aller beaucoup plus loin
dans ce code challenge, je n'ai pas seulement
dire cette figure réactive ou inactive.
Une
chose bête, on pourrait dire,
le fond de mon site, il est vert,
je veux essayer de le passer vert et je veux
mettre qu'à
un pourcentage de mes utilisateurs, on peut envoyer
cette info de le site et vert
via un figure flag et
pouvoir tester plein de choses comme ça
différemment à travers le temps.
C'est plein de choses
comme ça qu'on peut faire.
Après, je rebondis
par rapport à ce que tu viens de dire,
c'est vraiment excitant
de cette notion d'avoir
un killer switch,
cette notion de rémediation.
Je fais une feature,
je vois de la valeur,
mais je ne me rends pas compte de l'impact que ça va avoir
potentiellement sur le bon fonctionnement
de ma prod en période
de gros trafic et d'avoir cette possibilité
d'avoir un critère qui va dire
t'as envoyé un appel vers
une interface quelque part qui va dire
on envoie ça tout de suite parce que je vois
qu'il y a un problème majeur en production
je trouve ça génial.
Parce que du coup, ça rajoute
des mécanismes
dynamique
et moderne
pour la gestion de nos productions
et de fonctionnalités qu'on voudrait mettre en place
à un sociétaire. Donc ça va être vraiment excitant
pour le marché selon lequel on évolue.
Je trouve aussi qu'il y a nos trucs,
là je rebondis parce que ça me fait penser à ça
une idée mais il peut y avoir même un mélange entre
les deux qui est
en période de fort trafic
j'ai peut-être envie d'éliminer certains des appels
et seulement certains juste dans un moment. Je sais
que la fonctionnalité marche très bien. Je sais pas, j'ai
une fonctionnalité de chat par exemple à l'intérieur
de mon application qui prend énormément de bonnes passantes
énormément de ressources serveurs. Je me dis
en période de pique
je retire cette fonctionnalité que je sais
qu'il y a un impact sur mon backend
et j'ai pas envie d'avoir à scaler à l'infini
mon backend juste pour ça par exemple
et je rebondis encore là-dessus
c'est que de ce que je vois
apparemment, en tout cas
des exemples que vous avez donné
c'est qu'on a aussi bien des exemples très business
donc
j'active telle fonctionnalité
pour savoir est-ce que je vais avoir du MRR
en plus, n'importe quoi
comme revenu en plus
ou de l'autre côté des problématiques
très opérationnelles de je déploie
une fonctionnalité, je vais jouer un nom. Est-ce que
est-ce que ça serait pas un peu
le chaîno manquant un peu entre les deux
monde, ces future flags ?
Je pense que ça permet
de rendre le process
Blue Green deployment
ce que tout le monde peut connaître
encore plus
dynamique
je trouve ça
et en plus
d'avoir
cette capacité d'activer ou désactiver
en fonction des besoins, alors moi je dirais
si j'ai un problème de perf
et que je passe mon temps
à pallier, à activer ou désactiver des fonctionnalités
je pense que je prends le problème à l'envers
mais
oui effectivement je pense que pour un
je suis un SREP, par exemple, je gère ma
la Prod, je vois qu'il y a quelque chose qui impacte
fortement, je sais que c'est le composant chat
et d'avoir cette
souplace pour quelqu'un qui va
gérer la Prod, de dire disait active maintenant
parce qu'il y a un risque potentiel
je vous imagine, ça évite
de passer sur un redeploiement
un rollback ou n'importe quoi
et ça permet de corriger le problème
temporairement pendant la
phase de tricmets critique qu'on a pu rencontrer
en production
dommage je sais pas si tu veux rebondir là-dessus
sur la partie plus business, je pense qu'il y a aussi un vrai intérêt
business dans le sens où
on peut faire des choses qu'on ne peut pas
faire avec des déploiements
typiquement à use case que nous on avait
dans ma boîte d'avance
c'était en fait on teste en production
parce que
avoir les bonnes datas sur des environs
en prod c'est pas toujours facile
et donc
ce qu'on faisait c'est qu'on déployait
un flag avec la seule personne
qui pouvait accéder à cette nouvelle fonctionnalité
était un product manager, un QA
ou quelqu'un de ce type là
on validait que ça fonctionnait correctement
on ouvrait un petit peu plus large
avec des beta testers
soit internes, soit
des clients avec qui on travaillait
qui acceptait de tester les nouvelles fonctionnalités
et ensuite on faisait des relises
plus larges et plus business
pour l'ensemble de nos utilisateurs
c'est quelque chose
moi je pense qu'il y a un vrai intérêt
de se dire on change un peu de paradigme
tester en production
c'est pas quelque chose qui est facile
qui est iné et les feature flags
permettent d'avoir ça
quelque chose qui apporte beaucoup de valeur
parce qu'on a tous eu des pré-production
avec des data pourrie
où tout le monde dit bah oui mais ça vaut pas le coup
tester sur la pré-production
on n'est jamais sûr allons en pro
des croisons les doigts
là ça évite de croiser les doigts
ça permet d'être que sur ce qui va bien
après moi j'ai toujours eu
cette question
parce que moi je viens du monde de la PERF
je travaille plus de 15 ans dans
tout ce qui est ingénieurite PERF
optimisation de système et sur ce genre de choses
je me suis toujours posé
alors je trouve que le feature flag a amené plein
de fonctionnalités
et de valeur pour les projets
mais je me suis dit tiens mais en termes de PERF
je suis sur une version
d'une application qui peut être complètement
évolutive en fonction du profil
comment je peux mesurer
l'empreinte
d'une fonctionnalité quand je vais l'activer
il y a ce gros questionnement
moi c'est quelque chose que je me suis posé la question
à plusieurs reprises
après ça c'est ça nécessite
en fait une certaine maturité d'appart du projet
pour avoir cette mesure
et pour éviter d'activer un truc
qui peut être une bombe à retardement
donc d'avoir un process
qui permet de dire
tiens si tu actives cette feature
voilà les conséquences que tu peux avoir
sur tel serveur
sur tel composant
sur telle communication
je pense que ça ça peut être quelque chose qui pourrait
être à terme nécessaire
pour un sari
qui doit gérer la production
je sais pas si toi Thomas
tu as déjà eu dans ton cas
de test en prod si tu as déjà eu cette démarche
mais moi c'est les questions
qui m'est arrivé plusieurs fois
quand on a abordé le sujet en interne
oui et non
moi ce que j'apporte dans la librairie
que je développe il y a une fonctionnalité
qui s'appelle le progressive rollout
et en gros l'idée
c'est de passer de 0% à 100%
de mon flag sur une période de temps donné
et donc ça permet de se dire
peut-être que pour activer la figure
on va mettre au lieu de l'activer en une fois
de 0 à 100% on va mettre pas une semaine
et du coup pendant cette semaine
on va monitorer tout ce qui se passe
autour de ce rollout
idéalement
c'est pas quelque chose que je supporte aujourd'hui
mais idéalement on pourrait avoir
des marqueurs open telemetrie
type des traces
dans du tracing ou des chocs comme ça
pour qu'on puisse avoir
cette info que on est
sur telle variant
du flag et se dire
du coup on a ce comportement
et ça permet d'avoir du recul
et pas de se dire
j'ai testé sur 1% ça a l'air de bien se passer
et je passe mon flag à 100%
le faire progressivement ça aide beaucoup
pour ce genre de besoin
c'est vrai que les déploiements progressifs en fait
en fait
j'ai dit au début j'ai un plutôt du monde de Kubernetes
quand on parle de déploiements progressifs
on va penser à des déploiements
cubes
où on va dire j'ai plusieurs instances
et je vais les déployer petit à petit
mais c'est vrai que ça va être très compliqué
de se dire je m'arrête au milieu
pour tester les performances
notamment parce que souvent on a
des schémas de base de données
le déploiement a souvent besoin
d'être complet
les applicatifs ont du mal
à travailler ensemble
avec des versions différentes
c'est vrai que là, toi dans ce que tu dis
en tout cas et dans ta libre Thomas
on parle bien d'une seule
et même application à la même version
exactement, il y a une seule application
et en fait le flag a plusieurs variants
et l'idée c'est de passer d'un variant A
un variant B
progressivement
donc c'est à dire qu'on va donner deux dates
et dans ce moment là
progressivement il y aura de plus en plus
de users à tomber dans la nouvelle fonctionnalité
plutôt que dans l'ancienne
et donc ça permet, sur un seul applicatif
c'est le même pote
dans le Kubernetes partout
mais l'applicatif a deux comportements différents
d'accord
et donc va avoir à un moment donné
en fait c'est à l'application à devoir gérer ces deux fonctionnellements
là donc un seul schéma
mais qui va gérer deux comportements
exactement, si tu parles
en fait là, je pense que c'est ça
qu'il faut bien comprendre avec le FiturFlex
c'est qu'on amène de la logique
dans l'application pour gérer
toute cette notion
de blue green, de tout ça
c'est l'application qu'il le gère elle-même
alors que
historiquement dans le monde des srs et du DevOps
on avait plutôt tendance à mettre ça
en dehors avec les déploiements
des pods, du load balancing
ce genre de choses
là on sort de ça et on ramène ça à l'intérieur de l'application
donc ça n'a pas d'intérêt de faire du
progressive relou pour toutes les
fonctionnalités
mais pour certaines où on se dit
là ça peut être touchy, ça vaut peut-être le coup
de passer par ce genre de système
une question que je me pose
quand on parle
de est-ce que quelque chose va bien
donc Léonric tu as parlé de performance
c'est clairement le
point, en fait c'est qu'à un moment
comment se fait la remontée d'information
comment on sait que quelque chose
se passe bien avec un FiturFlex
c'est ça un peu ce qu'on a envie
de savoir à ce moment-là
pour moi après
je laisserai Thomas compréter
plus dans le détail mais pour moi
le code
dans le code on doit juste avoir ce logic de dire
est-ce que j'active ou pas
en fait il faut qu'il y ait un
système externe qui va lui
s'interfacer avec la brique de code
pour dire tiens je t'envoie
une notification d'activer ou pas
ce flag en fonction
d'un besoin donc du coup ça veut dire
qu'il faut
entre guillemets mapper un système
de sarpaïté
qui va lui se mapper avec
le système de FiturFlex
pour dire
là tout se passe bien on a activé
continue comme ça ou en contraire
tiens ça se passera très mal
désactive tout de suite
donc là on va dans un schéma de rémediation
on a une allie ou un problème
et c'est la rémediation pour résoudre
ce problématique ça va être
je vais envoyer une notification pour
désactiver la feature
pour résoudre temporairement le problème
de perfom.
c'est exactement ça c'est qu'aujourd'hui
il y a
peu de solution qui coupe
monitoring et FiturFlex en même temps
en général c'est plutôt décorré les
et comme tu monitor ton application
classiquement bah tu le fais
avec ou sans le flag
ça marche un peu de cette façon
donc typiquement des outils type open telemetry
ou ce genre de choses
marchent très bien en association
avec la FiturFlex
mais c'est pas la solution de FiturFlex qui t'apporte
cette observabilité
comment vous arriveriez à voir
cette jointement entre les deux
justement dans le bonifiture
quand le projet a
émergé il y a quelques idées qui sont sorties
du
sol
et l'une d'elles était ah ce serait génial
comme Thomas l'a mentionné tout à l'heure
ce serait génial qu'à partir du moment
où je passe dans une mec de code
que ça ajoute le contexte
nécessaire au sens open telemetry
pour dire je
FiturFlex un tel activé
donner un certain contexte
et donc appartement
l'application bien sûr génère elle
des traces au format open telemetry
ces contextes pour rajouter
et donc quand on est dans une solution
d'observabilité que ça peut être
des stacks Prometheus ou DINATRAS
ou autre on pourra
faire une recherche et dire tiens je veux voir que
les traces qui ont
ce fameux contexte open fiture
avec la version de Fiture
la Fiture en session en question et donc là on va pouvoir
ressortir que les traces
qui nous intéressent
Open telemetry aujourd'hui on parle de traces
on pourra très bien avoir des métriques donc on peut très bien imaginer
que
même l'open fiture va
avoir un petit compteur qui va dire
tiens
pour comptabiliser ça m'intéresse à
voir quelle proportion d'utilisateur
combien de personnes j'ai activé cette
fonctionnalité même si normalement on est censé
connaître en amont
mais si on a fait une boulette
ce qui peut arriver
d'avoir un comptage de dire tiens
j'ai 1000 personnes qui actuellement
utilisent cette fonctionnalité
ça peut être aussi une source d'information qui peut être intéressante
quand on fait la corrélation
lors d'une anomalie ou d'une problématique de production
ou à l'inverse
se rendre compte que le flag sert plus à personne
il faut aller t'y mettre au code
c'est justement
c'est ce dont tu parlais tout à l'heure qui est donc justement la gestion de ces flags
donc si jamais je résume
je me retrouve à avoir mon code
à avoir des if un peu partout avec du code
si telle fonctionnalité
si telle fonctionnalité
est-ce que mon code ne va pas devenir
un gros plat spaghetti
justement
à quel moment je peux savoir
ce que je vais activer et même est-ce que je peux me dire
que sur certaines fonctionnalités je vais les coder
dans un autre blob, enfin est-ce qu'il y a un moment même
j'aurais le moyen de me dire
telle fonctionnalité je les...
j'ai les développeurs NUD pour celle-ci
maintenant j'ai les développeurs en go
je veux le mettre sur du go
est-ce que tout ça c'est possible
et comment je vais justement gérer le cycle de vie de mon application
maintenant que j'ai des features flags
pour le coup ça c'est quelque chose qui est plutôt
intéressant avec des features flags
c'est que les flags ils sont
souvent pas liés à une technique
donnée donc il y a souvent des SDK
pour différents langages
et donc on peut avoir
plusieurs services qui écoutent le même flag
et qui décident de faire
et qui vont changer de comportement
en même temps donc
typiquement si tu veux
corréler une API avec ton front-end
pour être sûr que le front-end
qui est une single app en NUD
affiche correctement
le bouton pour que l'API
puisse le recevoir par exemple
activer le flag sur un user
ça va l'activer front-end et back-end
pour ce user-là donc ça a aussi cet intérêt
là d'être
quelque chose qui est en dehors
c'est très lié dans le code
mais c'est pas quelque chose
qui manipule un
un seul service
ou un seul application
ça peut manipuler plusieurs applications
et donc là dessus c'est très intéressant
d'avoir cette notion de
je pilote la synchronisation entre
plusieurs applications en même temps
donc typiquement
même si tu as des choses plus techniques
mais demain tu veux faire un switch de base
de données, tu veux passer
tu fais une migration
de pause gré et pour faire ta migration
t'as décidé de spawn un deuxième cluster
tu peux dire à un moment
je switch mon cluster pour tout le monde
et tout le monde va switcher en même temps
c'est aussi ça l'intérêt c'est d'être capable
d'assurer qu'il y a
une synchronisation entre toutes les services
au moment des changements
et sur le cycle de vie
des flags
en fait
il y a
il y a Martin Foller
tu m'as dit que tout le monde connait Martin Foller
mais qui les catégorise
en quatre différents types
de feature flags
avec des durées de vie différentes
il y a ce qu'il appelle des release toggle
des ops toggle
des permission toggle et des expérimentes toggle
l'idée derrière ça c'est que
chacun a une durée de vie plus ou moins longue
donc on va avoir des flags qui vont durer
quelques jours, d'autres qui vont durer
quelques semaines, d'autres qui vont durer peut-être des années
et donc l'idée c'est
de bien les catégoriser
quand on les crée pour le savoir
que ça existe et savoir lesquels il faut
checker plus régulièrement que les autres
dans sa configuration pour savoir
lesquels on garde et lesquels on supprime
après
il y a sur le contexte
Open feature
en fait sur la gestion
sur ce qu'on voulait activer et pas activer
on a eu tout de suite cette
comme on évoluait dans le monde
essentiellement de Kubernetes
on s'est dit
tiens on va prendre
des logiques Kubernetes qui sont
simples et faciles à mettre en oeuvre
et donc c'est l'un
des composants sur lequel a été travaillé
c'était Open feature opérateur
et justement d'avoir quelque chose
qui est externe code et on détermine
en fait le flag
s'il est activé ou pas
et après derrière en code il y aura toujours cette notion
de if mais cette notion
de
les variantes
les données
qui vont activer ou pas le flag
et ces autres choses vont sortir
dans un sade cas et donc on essaie
de
pas simplifier le code
mais parce qu'on a toujours
c'est une partie dans le code
mais de standardiser et faciliter
la mise en oeuvre d'Asya feature flag
donc je trouve que c'est
un peu plus important
de travailler dans un monde Kubernetes
je pense que ça facilite
ça faciliterait
énormément la adoption et la mise en oeuvre
et éviter
de créer une grosse nébuleuse avec plein de
pas comme tu me disais tout à l'heure
si on a des if partout ça devient
il faut que je développe ma fonctionnalité
après il faut que je développe la communication
2 après 3 il faut que je gère
les Open feature
après il faut que je mette de l'instrumentation
de la maitrie
mais finalement j'ai passé mon temps
que 20% à faire ma feature le reste
j'ai fait tout le reste pour faire tout ce qu'il y a autour de mon code
et là on se dit mince
c'est bizarre quand même
mais je pense qu'avec des systèmes
comme ça on peut essayer de gagner un peu de temps
à rentrer à gauche
notamment sur la partie observabilité
je pense que c'est là où il y a le plus
grand intérêt sur Open feature
c'est qu'on la délègue
à un composant qui va la gérer
pour nous en fait
et peu importe le provider
ça va être géré tout le temps de la même façon
donc c'est un gros avantage
de fonctionner comme ça
et est-ce qu'une façon de faire
ça peut être aussi d'utiliser des API getaway
est-ce que brancher ça
est-ce que ça aurait un sens
d'avoir une API getaway
qui va aller envoyer un flux
sur un autre
enfin sur un blob ou un autre
d'ailleurs de se dire au lieu d'avoir tout dans le même code
de se dire j'ai blob1 qui est fonctionnalité 1
blob2 qui est fonctionnalité 2
blob3 qui est fonctionnalité 3
qui sont fait d'une certaine façon ou d'une autre
c'est pas ça le problème
et je vais router
tout mon arbre comme ça
en fonction de la fonctionnalité
est-ce que c'est aussi une possibilité ?
si tu me refer as un peu des fonctionnalités de service mesh
comme le traffic split qui le fait
mais le problème c'est qu'effectivement
là on n'a pas cette capacité
de dire
je veux le faire que pour
je sais pas moi une zone géographique
ou que pour un utilisateur
qui est inéterné
donc si on veut mettre ça en oeuvre dans un traffic split
faire cette logique là
ça veut dire qu'il faut remettre en plus une couche
au dessus qui va lui
configurer le traffic split en fonction
et ça devient une usine à gaz à gérer
on pourrait la voir
typiquement comme dans hotel on a une ID transaction
pour très bien avoir quelque chose qui fait la
remédiation entre les deux et qui dit
telle transaction
je la connais parce que
j'ai déjà des informations sur elle
et après je vais faire des choses en fonction de ça
en fait le but c'est de se dire
tout est un ID unique qu'on passe
de blob en blob qu'on se passe
et on va faire des actions en fonction de ça
on pourrait très bien avoir cette notion là qui apparaît
à ce moment là
oui ça pourrait être mais je pense que ça serait
à gérer
sur du long terme
et sur les évolutions de l'application
parce que l'application va évoluer dans le terme
avec les d'autres features et de choses
ça devient une usine à gaz je pense
à maintenir après je sais pas
c'est mon avis Thomas je sais pas si tu...
non non je suis d'accord là dessus et surtout
quand
tu es dans une entreprise qui a vraiment adopté
les features flag on parle de création
de flag de dizaines par semaine en fait
ou de
ouais on voit même plus que ça
et donc du coup si à chaque fois tu dois créer
un nouveau service avec une nouvelle route
sur des choses tu te retrouves dans une situation
un peu compliquée et surtout
tu peux... si on parle
je sais pas si tu as 200 features flag activés
sur ton application ou sur ta grappe on va dire
il y a des combinaisons aussi
de gens qui vont avoir peut-être
15 flags activés et 25 pas activés
et donc gérer ça
avec des déploiements différents ça rend
forcément la chose un peu compliquée parce que
tu perds cette granularité
que tu pourrais avoir avec
l'opéra d'avoir mis ça dans ton
code en fait directement
tout à l'heure tu en as parlé un peu Thomas mais
est-ce que... ce qu'on peut aller plus en détail
est-ce que ça change quelque chose dans la façon
de travailler je veux dire un peu
au quotidien d'un développeur en fait
là si vraiment on se sente sur la partie
de développement est-ce que ça va avoir un impact
sur la façon de travailler
typiquement ce que je pense quand je dis ça
c'est le fait qu'aujourd'hui
on a plein de gens qui sont dans
des sprints scrums etc
qui font leur fonctionnalité
puis après ils ont besoin d'une review
et en fait cette review des fois elle prend des semaines
ce qui fait qu'ils se retrouvent à avoir fait une fonctionnalité
qui peuvent pas dire qu'elle est finalisée
parce que
pas encore le Tika il est pas clos
la PR est pas emergée pour
x ou x horizon
est-ce que justement il y a pas
un impact à ce niveau là et peut-être même à d'autres endroits
dans la façon de travailler
moi dans l'idée
déjà une review qui prend des semaines c'est toujours
dommage
mais ça arrive
l'idée derrière ça c'est justement
d'organiser
son équipe avec cette volonté
de
mon code a été écrit
je le délivre le plus rapidement possible en production
encore une fois délivrer en production
on veut pas dire
nouvelle fonctionnalité accessible
ou pas ça amène aussi
beaucoup plus d'itératif
moi ce que j'ai constaté c'est que souvent
les poules request sont un peu plus petites
parce qu'on peut pousser du code dans production
qui ne sera pas activé pour personne
mais au moins qui apporte
une première étape donc on peut faire des étapes
en disant je fais un
pré MVP que je bouge jusqu'à la production
on valide ce pré MVP
je passe sur un MVP puis après
sur la finalisation de la feature
et tout ça à chaque fois c'est des déploiements
qui vont jusqu'à la production alors que souvent
aujourd'hui c'est des choses qui vont rester
au stade pré production
avec au QA
avec des gens qui vont tester ça
et qui vont dire c'est pas encore parfait
on attend avant de le déployer
l'idée derrière ça c'est que
comme on réduit la taille des changes
on réduit aussi la taille des poules request
donc la taille des
des revios est souvent de meilleure qualité
parce qu'il y a moins de choses à revios
c'est plus petit
le trade off par rapport à ça
c'est qu'on doit maintenir
deux features dans le même code
et ça à des fois ça peut poser problème
parce que ça nécessite aussi
d'avoir un code plutôt bien écrit
pour éviter d'avoir un refactor
à chaque fois que tu as besoin de rajouter un flag
quelque part
parce que c'était pas assez modulaire
parce qu'on se retrouve au milieu
d'un code très legacy et qu'on veut changer
le comportement
là c'est plus compliqué
donc souvent si tu es dans une équipe qui écrit
correctement son code, qui met plein de petites fonctions
ce genre de choses c'est assez facile de passer
d'une feature à une autre
c'est moins le cas quand tu as du code un peu spaghetti
sur lequel c'est un peu plus compliqué
d'amener ça
après c'est sûr que je pense que ça nécessite
une certaine maturité
ou une certaine organisation
un certain mindset
dans la manière dont on travaille
parce que même la manière dont on va structurer le code
Thomas a mentionné
si on commence à faire quelque chose qui est très nébuleuse
et on veut mettre ça en feature flag
après on va gérer des différentes fonctionnalités
avec différentes... ça devient
une usinia gaze
je pense que ça nécessite
au sein des équipes déjà de se
préparer à la démarche
pour se s'organiser et structurer son code
de la bonne manière pour que ce soit un succès
et non un échec
et est-ce qu'on va apparaître
justement à un moment
des façons de coder
des façons de
créer son code qui vont être différentes peut-être
parce qu'on va avoir de nouvelles pratiques
on va peut-être avoir un jour des frémoires
qui vont être feature flag natives
on va dire
si jamais ce terme un jour existe
alors je pense que pour que ça arrive
il faut qu'on ait une solution type au peu de feature
qui standardise un peu tout ça
ce qui n'était pas le cas jusqu'à aujourd'hui
en vrai les bonnes pratiques de développement
se marient très bien
avec la gestion des feature flag
c'est à dire si on découpe correctement son code
qu'on a des
bonnes séparations
c'est pas chine of concern, des choses
ce genre de choses ça aide beaucoup
à structurer
à être efficace dans les feature flag
si on est
sur des fonctions
de 200 lignes et qui font le café
ça sera
compliqué
c'est là où je rejoins Eric
sur la partie maturité
c'est à dire que
si c'est déjà compliqué d'écrire du code de qualité
rajouter des feature flag ça va pas aider
ça va même peut-être amener de la complexité
et potentiellement des bugs
parce qu'on va devoir refactor pour pouvoir mettre en place
les flags et donc peut-être que ces refactor
vont casser la production
après il y a un autre point
on y pense pas mais il y a la correction de bug
j'ai un bug
quel est le process de correction du bug
enfin c'est ce genre de question
quelqu'un qui n'a jamais mis de pied dans ce monde
peut se dire attend mais
je fais un nouveau feature pour corriger le bug
ou que je suis perdu
oui est-ce que je corrige dans le nouveau
dans l'ancien déjà le bug il a réparé
à quel endroit enfin c'est vrai qu'il y a pas mal de questions
de nouvelles questions à se poser
typiquement
c'est quelque chose qui arrive
souvent quand on travaille avec les feature flag
la première chose qu'on fait quand on a un bug qui est remonté
c'est regarder
si l'utilisateur qui remonte le bug
est tombé dans un flag ou pas
et c'est bien d'avoir
se réflexe de se dire
ok il est dans tel flag donc potentiellement
il peut avoir
le bug va se retrouver dans l'utilisation du flag
et pas dans le reste
et c'est là où avoir du bon monitoring
bien noté
dans quelle variation du flag
l'utilisateur a pu tomber et être beaucoup
parce que sinon on peut se retrouver
essayer de débugger pendant des jours alors qu'on était
sur l'autre variant
d'où l'intérêt de l'observité
exactement
en fait c'est marrant de voir ça
mais quand des bonnes pratiques développent
sur plein d'autres concepts
et en fait c'est les projets modernes
en fait on se voit très bien
que si on n'a pas d'observité en place
ça rend les choses très
compliquées que ce soit
des tests de automatiser
valides
que ce soit
des pratiques SREs en production
que ce soit enfin
aujourd'hui en fait si on n'a pas une observité
aujourd'hui on a du difficile
on peut avancer
mais on avance avec énormément
de lourdeurs
et puis on n'est pas sûr de ce qu'on fait
c'est surtout ça
ce qu'on voit là c'est que
les features viennent après
pas mal d'évaluations
qui sont apparues
c'est vraiment
une suite de choses dont on a besoin
pour arriver
à ce dernier maillon en fait
on est un peu dans le dernier chose
vous pensez que ça va apparaître
vite est ce que vous pensez que c'est
à l'échelle ça va être une technologie
qui va exploser dans les prochaines semaines
mois ou années
à quel point vous voyez
une traction par rapport à ça
par exemple on va prendre
un sujet comme OpenTelemetry
c'est le deuxième plus gros projet
chez CNCF après Kubernetes
il y a énormément de
contributeurs, de ripos
différents aujourd'hui on va dire
quand on regarde les gens
quand on est venu dedans on comprend le concept
d'OpenTelemetry
mais ça n'est pas
encore arrivé dans les oreilles
de tout le monde, ça reste quelque chose
d'assez encore très considéré comme innovant
après il y a cette notion
aussi de stabilité
si on met en place
un projet comme OpenFiture il faut
un que les specs soient
en compte de finalisation mais que les specs soient bien finalisés
que les SDK sont bien construits
et bien matures
qu'il y ait suffisamment de documentation
suffisamment d'exemples
et après il y a un vrai travail
d'évangélisation
parce que un projet comme OpenFiture
qui peut être très séduisant
sur le papier
il peut passer quasiment inaperçu
et c'est un peu dommage
c'est un peu la fraisheur
de tout projet, toute personne
qui contribue dans ces projets là
de se dire je ne sais pas envie de devenir
un nouveau IPv6
c'est à dire on sort à technologie
puis en fait quand on regarde
notre tour de l'eau je ne sais pas s'il y a beaucoup de serveurs
qui tournent dans IPv6
mais c'est un peu le drame de se dire
on investit beaucoup de temps et d'énergie
pour finalement à rien
donc je pense que la d'option
elle passe sur le dévangélisation
sur la qualité de doc
la qualité d'exemple
sinon je pense que ça
n'arrivera pas dans la main de tout le monde
et pour répondre à ta question
Guillaume je pense que c'est
déjà en train d'exploser
sans standard
il y a des boîtes comme Lounge d'Archie
dont je parlais tout à l'heure qui sont très successeful
il faut beaucoup d'argent
et sont très suivis
dans le monde du future flag
mais on
ça reste confidentiel
dans le sens où on se lock un vendor
et je pense que
c'est de moins en moins l'envie des gens
et donc des open features
qui la portent c'est juste une espèce
de couche d'abstraction devant
devant les vendors
et en plus toute la partie
Open telemetrie
et toutes ces standardisations
c'est vrai que c'est assez nouveau
comme projet
et ça débute seulement
mais c'est assez prometteur pour les gens qui travaillent
autour de tout ça
et surtout tous ces gros vendors
pour le moment sont intéressés par le sujet
donc c'est plutôt bon signe
pour la suite
et justement si on fait un focus
sur Open telemetrie
je sais pas si Henri tu connais un peu sa gênèse
comment s'est apparu
autour d'un bar
et maintenant où est-ce que ça en est
et où est-ce que ça va
le projet en fait c'est Open telemetrie
c'est le merge de 2 projets existants
donc c'est Open census
et Open metric
donc il y avait 2 besoins
qui couvraient 2 choses différentes
il y avait un côté élémétrique
et d'un côté il y avait la trace
le projet avait bien maturé
et après il y avait
une vraie volonté de se dire mais pourquoi on ne marche pas
l'effort et on crée quelque chose de standard ensemble
et appartement
il y a eu le standard qui a été mis en oeuvre
il y a eu un vrai travail
tous les différents vendors
pour arriver à mettre en place ce standard
ce qui est génial
et aujourd'hui
à l'heure actuelle on est donc les traces sont stabilisées
la plupart des langages
on dispose d'un SDK
ou des ingents
soit manuel soit auto instrumenté
et après derrière
il y a l'émétrique qui vient de sortir
on dirait la spec qui était finalisée
et la plupart des
des langages commencent à l'implémenter
donc il y a quelques langages qui sont en avance par avoir d'autres
mais aujourd'hui on va dire
aujourd'hui à l'heure actuelle on est
mieux que il y a quelques années
quand on avait les 2 frameworks séparés
donc déjà c'est quelque chose de très
réconfortant de dire on essaie
au moins déjà on a franchi l'étape
pour qu'on est mieux qu'avant
et là ce qui est excitant c'est que maintenant
les logs sont en cours d'implémentation
de
enfin la spec est en train de se finaliser
et l'implémentation va se faire après
et il y a un autre sujet qui est en train
de rentrer dans le scope de pentamétrie
donc je cas présent que la pentamétrie couvrait
en la volonté
de couvrir les traces dans un premier lieu
les métriques et après les logs
et là on commence à aborder le sujet
qui est très excitant c'est le continuous profiling
qui va être également
un élément
donc ce diaire tiens j'ai une trace
et puis après tiens c'est bizarre
j'ai un bloc qui est lent et pourquoi c'est lent
et donc tu es après d'aller directement dans le profiling
grâce au trace ID
associé je trouve ça génial
et encore aujourd'hui je pense que
on a des organisations qui commencent
à le mettre en oeuvre il y en a beaucoup
il y a beaucoup d'organisations qui sont en mode POC
qui regardent la technologie
de loin, tiens
j'ai peut être utilisé mais j'ai peur
que ce soit
de te confronter à des promes d'instabilité
et après il y a des organisations
là ce matin j'étais avec
un client qui est en Australie de New-Mais-Èlande
et une grosse banque
d'Australie de New-Mais-Èlandais
et ils ont emplémenté OpenTemperie partout
et donc là on voit une question
de maturité déjà mais déjà
ils ont fait de l'investissement
et la mise en place de ces gens de choses
pour avoir une
une traceabilité complète à 360°
de ce qui se passe
et donc ils ont complètement compris la valeur
et ils l'ont mis en oeuvre
bien avant certaines
autres organisations
donc je trouve que c'est avoir cette possibilité
de dire tiens j'ai un standard
d'instrumentation qui n'est pas
encore attaché à un vendeur
spécifique
et de pouvoir dire tiens si moi je fais
une partie de mon code et puis je tombe dans Salesforce
et puis après une fois que c'est
rendu dans Salesforce je suis complètement dans le noir
mais si Salesforce
fait aussi de l'OpenTemperie et ça se trouve un jour
je pourrais avoir vraiment la transaction
end to end de bout en bout
et comprendre où est ce situ
le problème et je trouve ça
génial en fait pour le futur
de la gestion de notre prod
nos environnements, des practicaceries
des ingénieurs de perves
de fin de tout
donc non non c'est
un projet comme ça aujourd'hui on va dire
qu'adoption elle se fait petit à
il y a une grosse connaissance, une grosse popularité
du projet mais l'adoption elle se fait
vraiment encore étape par étape
et comme on va dire
ce qui a rendu
compliqué OpenTemperie
c'est la grande
nombre de RIPO, Git
qui sont sur OpenTemperie
le niveau
disparate
de la qualité des docs
et des exemples
et donc c'est vrai que du coup
l'expérience quand on rentre dedans
elle peut être géniale
ou ça peut être
très très très un enfer
donc c'est là où je pense qu'il y a
la vraiment la volonté et la communauté
d'améliorer tout ça pour
accroître l'adoption et créer un vrai succès
et donc si on vient
sur OpenFiture
ça veut dire qu'on essaye
d'avoir la même chose parce que là en fait
si je reprends la genèse un peu d'OpenTemperie
il y avait donc deux projets
assez à succès on va dire
qui étaient quand même assez connus qui ont mergé
là OpenFiture
part de rien donc quelle était la
genèse ou est-ce qu'on en est
et pareil où est-ce que ça va
sur OpenFiture en particulier
OpenFiture c'était le besoin
était tout ce qu'on a
pu relever comme challenge en fait
c'est génial comme fonctionner
enfin, le future flag c'est génial
mais il y a
c'est quand même très dommage
d'être très limité
à des SDK
ou des librairies d'un vendeur
et donc pourquoi pas mettre un standard
sur le marché donc c'était vraiment
cette volonté de dire si on met un standard
aujourd'hui que tous les éditeurs
travaillent de main dans la main on va arriver
à avoir un standard qui va
dans un
directement faciliter
l'adoption même si elle est
comme Thomas l'a dit il y a comme un grand
nombre d'utilisateurs qui sont sur la
long story clip ou de solution mais carrément
généralisé et devenir
un process quasi-immense standard
de développement dans le futur
et donc quand le
projet a démarré il y avait cette volonté de dire
ok on va essayer de faire des choses
sans passer par la case erreur
enfin au moins prendre
les retours de projets qui ont
démarré avec difficulté et puis
essayer d'évité
de tomber dans
des trous ou des
éléments qui vont nous freiner ou nous
ralentir dans la création du projet
donc ça apprend par rapport
aux échecs. Et c'est Dynatras
qui l'a lancé ou c'est une initiative
personnelle ? C'est une initiative à quel niveau
ça s'est fait ? Alors c'est Dynatras qui l'a lancé
donc c'est deux ingénieurs
de Dynatras et puis après
tout de suite c'est dit y a un standard
il faut qu'on
ait des contributeurs, il faut qu'on
contacte les sociétés qui
cravit
autour de ce domaine
pour que chacun puisse contribuer
et amener sa patte
et faire de ce projet
qui semble sur le papier très sexy
mais d'en faire un vrai projet qui
sera vraiment utilisé. Et donc toi Thomas
justement là-dessus tu t'as dit que t'avais
contribué à OpenFittures
toi ou est-ce que t'en es dans ta contribution
et comment tu l'as connu et ce que
tu peux en dire ?
Comment je l'ai connu
juste pingué sur Twitter un moment
et j'ai eu l'occasion
de parler avec les gens de Dynatras
justement autour de tout ça
moi pour le moment je me focus sur deux choses
côté OpenFittures
la première c'est de mettre en place les
providers pour GoFittureFlag
pour donner que
de la façon dont fonctionne OpenFitture
il y a un SDK de base et on peut
implémenter des providers
spécifiques à chaque vendor
pour pouvoir derrière
que le SDK appelle ce provider
et l'amène
là-dedans. Donc ça c'est la première partie
c'est plutôt pour
rendre mon produit compatible
et la deuxième il y a
une initiative qui s'appelle FlagD
qui est
une solution
de feature flag qui ressemble
un peu à ce que moi je fais
avec GoFittureFlag mais qui est
l'idée c'est de faire une solution
simple
sans vendor complètement open source
à partir de fichiers plat
de feature flag pour pouvoir
expérimenter
OpenFitture
sans avoir un contrat avec LaunchDarkly
avec FlagSmith
ou d'autres choses de ce type
Aujourd'hui
c'est assez
nouveau OpenFitture
moi je contribue aussi sur la partie spec
pour pouvoir proposer
des choses, voir s'il y a
des choses sur lesquelles on peut
améliorer
ce qui était prévu dans l' SDK
ce genre de choses donc pour le moment
c'est une toute petite communauté
je crois qu'il y a
moins de 100% sur le Slack
mais des actifs
je pense que ça se compte
en 20 de personnes
donc du coup il y a beaucoup de choses à faire
si jamais ça vous intéresse n'hésitez pas
à venir contribuer
mais c'est intéressant de voir vers où ça va
et de voir que c'est
vraiment un projet qui est drivé par la communauté
il y a quasiment tous les SDK
dans tous les langages qui sont en cours
de création ou finalisation
je sais qu'il y a déjà un SDK
JavaScript qui existe mais il y a
un Go, un Java
un Python qui sont en cours de
développement
il y a un peu tout ça qui avance
et qui
permet
de fonctionner avec OpenFiture
et moi dans l'idée
à long terme pour la librairie
et pour ce que je fais
avec OpenFitureFlag
moi je me mettrai bien dans un mode
où je ne fais pas de SDK pour ma solution
et je me repose
uniquement sur OpenFiture
pour cette partie-là
moi ça me fait moins de maintenance
parce que c'est bien un project pour moi
et surtout ça le rend
de fait standard
vers où le FutureFlag va en ce moment
cool
je sais pas si vous avez
déjà fait un grand tour
du FutureFlag
je sais pas si il y a autre chose
que vous voyez dont on aurait pu ne pas parler
non je voudrais juste
remettre l'accent sur ce que Thomas vient de dire
si vous trouvez que le projet est
intéressant
n'hésitez pas
à venir contribuer
donc si vous voulez chercher adresse c'est
openfiture.dev
vous arrivez sur le site web de OpenFiture
qui est assez light en ce moment on va dire
mais en vous aurez accès aux différentes spécifications
différents projets et puis
n'hésitez pas à venir contribuer
la communauté est enjeune
elle va grandir
et puis c'est grâce à la communauté
que le projet serait un succès
et qu'on pourra
généraliser son utilisation un peu partout
et Thomas tu as dit que tu avais aussi ton projet
est ce qu'on peut contribuer
avec toi sur peut-être justement
l'implémentation d'OpenFiture
sur ton projet
avec plaisir
l'idée de ce projet
quand je l'ai créé c'était de faire
une première solution de FutureFlag
sans avoir contacté un vendor et commencer
faire des choses et il y a encore plein de sujets
qu'on peut faire pour améliorer la solution
et tous les gens sont les bienvenus
pour contribuer également
je vais aussi faire ma pub
gofitureflag.org
et normalement derrière
il y a tous les liens vers les ripos
et tout ce qu'il faut pour pouvoir
contribuer
c'est cool j'espère que ça donnera envie
à des gens
et au moins de s'intéresser
mais d'y passer pour utiliser
des livres déjà existantes
ou de contribuer
à OpenFiture
je comprendrai pas que là
les gens ne se lancent pas
ou au moins essayent en mode POC
comme tu l'as dit à la Reinerik
pour l'OpenTelemetry
là que des gens se mettent à faire des POC
sur OpenFiture
et sur du flagging
pour le coup là-dessus
sur le ripo d'OpenFiture
il y a un ripo qui s'appelle Playground
où il y a des POC
pour différents vendors
et donc n'hésitez pas à aller voir
à quoi ça ressemble et à jouer avec
si vous voulez
il y a moyen de monter l'app
en quelques secondes et commencer à voir
à quoi ça ressemble
c'est une bonne conclusion
merci à tous les deux
merci beaucoup
alors là pour vous dire c'est quelque chose qui s'est organisé
vraiment
on ne se connaissait pas trop avant
le début de ce podcast
on s'est pingé sur Twitter
avec des gens des pings de roping etc
et nous voilà pour enregistrer
si jamais vous voulez parler d'un autre domaine
de celui-ci si vous voulez rebondir
parce que vous avez aussi une expérience sur le future flag
ou sur d'autres sujets
n'hésitez pas à me contacter
pour faire ça
merci vraiment à tous les deux
Thomas et Améric pour avoir participé
merci à vous
merci pour nous avoir amené
d'organiser et de produire ce podcast
c'est utile pour la communauté
pour qu'ils découvrent des sujets comme OpenFuture
c'est super chouette
merci beaucoup pour ce moment
merci pour ce moment
très bien et à une prochaine alors
salut