Dorra Bartaguiz - Le feature flip pour réussir à avoir du flow

[00:00:03] Bonjour tout le monde. J'espère que vous allez mieux que moi, en tout cas. Je suis un peu malade donc j'essaie de de tenir le rythme mais ça va le faire. Euh, bienvenue à ma session euh comment améliorer l'implémentation des feature flipping. Euh, qui a déjà utilisé des feature flipping ou du des flips, on va dire en général? Parfait.
[00:00:28] OK. Il y a pas mal de monde. Alors, euh, moi j'aime bien toujours commencer par me présenter déjà. Euh, je m'appelle Dora Bartaguis, je suis Fille Pidec chez Arola, euh, donc je fais partie de la direction technique d'Arola. Je suis aussi co-auteur d'un bouquin qui s'appelle Software Craft aux éditions Dunod et euh j'ai plusieurs casquettes puisque je suis dev depuis euh plus de 16 ans maintenant et euh je fais plutôt des missions de conseils et de coaching actuellement. Donc voilà. Et j'ai été aussi prof à une école d'ingé à Paris. Arola c'est quoi? C'est une ESN parisienne, on a un stand si vous voulez passer on parler plus. Mais on fait principalement de l'assistance technique, de du conseil, de du coaching et aussi on est un centre de formation, donc tout ce qui est autour du craft. Donc TDD, les pratiques qu'on connaît TDD, BDD et Domain Driven Design mais aussi au-delà de tout ce qui est aussi technique aussi par rapport au dev. Je voulais commencer parce que ce talk, je l'avais pas forcément prévu avant et en fait tout a commencé sur X, Twitter. Euh par une discussion ou plutôt une question de Jordan à l'époque, euh il demandait quel est le notre feedback par rapport au feature flipping. Et ma réponse elle était un petit peu négative pour certains. Euh puisque je considérais ça comme un smell. Et donc euh après une longue discussion sur Twitter, comme comme d'habitude. J'ai proposé, enfin j'ai promis un article pour parler dessus. Euh et puis il y a Yannick qui m'a contacté un des organisateurs de Floken qui m'a dit bah je veux bien en parler parce que ça serait un sujet intéressant pour Floken. Et apparemment j'ai bien vendu le sujet donc je suis là.
[00:02:18] Voilà. Euh, donc à partir de ce moment-là, euh, ça j'ai commencé le travail. Euh j'ai commencé par euh squetche un petit peu euh qu'est-ce que je enfin de quoi je vais parler. Et puis j'ai proposé aussi le sujet dans ce qu'on appelle chez nous les forums ouverts chez Arola, trimestriel. C'est des espaces, je suppose que vous connaissez ce que c'est qu'un forum ouvert, c'est des un conférence, il y a pas de planning prévu pendant la journée. Et puis en parallèle de ça, j'ai lancé une une enquête. Je sais pas si vous l'avez vu passer sur LinkedIn, Twitter ou autre réseau. Euh n'hésitez pas continuer à participer si vous voulez. Euh, donc à partir de ce de de ces deux inputs là, euh j'ai commencé à à faire un un vrai recherche, enfin un vrai travail de recherche pas euh dans ce sens-là, mais on n'est pas loin. Donc je voulais déjà remercier toutes les personnes qui ont participé à la à l'enquête, euh que ce soit par des réponses direct ou indirect et tous les aroliens et aroliennes qui ont aussi enrichi ce ce talk là. Et pour revenir à l' à l' à l'enquête, effectivement, il y avait 92 personnes qui connaissaient euh 92 % des personnes qui connaissaient déjà le feature flipping parce que c'était la première question de de l'enquête. Et il y avait un espèce de consensus sur la définition. Euh, déjà euh avant de passer à la définition, moi je veux passer déjà par les noms utilisés parce qu'on parle toujours de feature flipping. Mais il y a plusieurs noms. On parle de flipper, de flag, de toggle, de switch, de conditional feature. Je sais pas si ça vous parle tous ces mots. Probablement. Et euh qu'est-ce que le feature flipping? C'est j'active, je désactive une feature euh dans le temps en temps réel sans livrer du code. C'est ça le but. Donc ça veut dire quoi? Ça veut dire que j'ai besoin d' ce qu'on appelle une activation multiple d'une même feature. Donc elle est désactivée, je l'active, je la désactive un certain temps, je l'active et puis je la désactive et cetera. À l'image un peu de la de l'électricité dans la maison. Donc vous avez l'interrupteur, c'est votre flip ou flipper, plutôt, ou toggle ou flag. Donc quand c'est une petite feature à l'image d'une pièce, bah ça sera l'interrupteur qui est votre flipper. euh au niveau de la maison, ça sera le dans le tableau euh d'électricité. Quand il s'agit d'un immeuble, ça sera plutôt le panneau électrique ou le tableau de répartition d'énergie. Et puis là, plutôt, on est plus dans une feature mais plutôt une épique. Et là clairement on n'est plus dans une feature, ni épique d'ailleurs. Euh, la première fois que j'ai vu euh les feature flip, comme la plupart d'entre nous, je suppose, c'est en mission. Donc j'arrive en mission, on m'explique que toutes les features qu'on va développer, il faut avoir un toggle ou un flipper euh avant même de penser à implémenter quelque chose. Et le but c'est de la livrer en tout cas en désactivée et ensuite l'activer si besoin.
[00:05:27] Et donc on avait à chaque euh comment dire? à chaque feature, un flipper associé, qu'on configurait en base et on active ou on désactive. Et ma première question, c'était pourquoi on faisait ça pour toutes les features? Parce que normalement, une une fois qu'on a une feature spécifiée, identifiée, on a un besoin derrière, c'est qu'on a besoin de l'activer en prod. Donc pourquoi on le faisait dans toutes les features? Et la réponse était: Mieux encore. On a toujours fait comme ça. Classique.
[00:06:02] Donc en fait, ma réaction c'était en fait si on a besoin de le faire tout le temps comme ça, c'est que réellement le besoin n'est pas clair. Ou du moins, on n'a pas identifié réellement si on a besoin d'un feature flip ou flipper pour ce cas-là. Et plus le temps passait, plus je me rends compte que l'utilisation qu'on faisait des feature flipper n'était pas forcément la meilleure. Et donc il y avait quand même un travail potentiellement à faire. Et donc j'ai commencé à à mettre le nez dedans et euh j'ai commencé à creuser un petit peu sur le projet déjà dans lequel j'étais en analysant tous les feature flipper qu'on avait euh qu'on avait et en regardant le nombre de features actives par rapport à celle inactive. Est-ce que ça, quand est-ce que ça a été mis en prod? Euh est-ce que ça a été effectivement désactivé à un moment donné? Est-ce qu'il y a une différence entre des environnements? Est-ce que il y a un ménage fait par rapport au flipper? Parce que je suppose que une fois qu'elle qu'on l'a activé en prod, c'est qu'il y a plus besoin de d'avoir ce flipper là, on est serein avec la version qu'on va livrer. Et euh au résultat du compte, c'était un peu le bazar. Le bazar parce que
[00:07:18] en fait, réellement l'utilisation des flippers n'était pas adaptée à notre besoin. Du moins euh à l'époque de l'équipe, enfin dans l'équipe où euh où j'étais. Et après, il y avait plein d'inconvénients euh qui venaient avec justement l'implémentation qu'on faisait avec le feature flipping. Le premier, c'est que les flippers n'étaient pas supprimés. Ensuite, il y avait des multitudes de if et des configs à gérer. Je vous laisse imaginer un petit peu le le code. Donc le code des moins lisible, on sait plus quel est le if métier du if configuration technique par rapport au flipper et puis le coût supplémentaire d'analyse. C'est que si je fais ma feature euh et puis ça chevauche avec un autre flipper, quelle est l'impact derrière? Si je désactive celle-là et je réactive l'autre, comment ça se passe? Donc on avait vraiment beaucoup de un coût supplémentaire d'analyse à faire pour ne pas se retrouver à je désactive une feature et puis il y a une partie de cette feature qui est liée à un autre flag ou un autre toggle de l'autre côté et on est un peu dans la muse.
[00:08:25] Et euh donc ça c'est la dépendance des flippers et puis après, il y a aussi la problématique de des tests. Donc que ce soit côté dev ou côté QA. On avait des tests de non-régression à faire à chaque fois en mode off on de toutes les de tous les flippers qu'on avait dans dans la base. Donc il fallait faire attention à tout ça.
[00:08:46] Si on prend un exemple, imaginez que le rectangle correspond à un scope dans le code et euh c'est pour activer un feature un flip euh une feature, pardon. Donc parfois on a la même feature mais dans deux endroits du code. Donc on a un if qui se balade dans un coin et puis un autre de l'autre côté. Et puis on rajoute des if et puis euh on a plein de if partout. Euh sachant que ça se chevauche et cetera. Et souvent, on a des un code qui ressemble à ça. Euh si ma feature est enable, euh alors et j'ai aussi une contrainte métier avec, alors je fais ça. Ce qui fait que on n'arrive plus à distinguer, est-ce que c'est une condition métier purement métier ou est-ce que c'est une condition avec un flipper derrière? Donc quand on essaie d'identifier ça dans une méthode à part, on s'en sort, mais souvent c'est un peu le bazar. Ce qui fait que en en fin de compte, on se retrouve avec des développeurs et des développeuses soit tristes, soit carrément en colère et puis euh ceux qui sont bons, bah, ils désertent. Ils quittent les projets parce que c'est c'est le bazar.
[00:09:56] Donc ce que je propose, c'est déjà pourquoi on a besoin d'utiliser le les le feature flipping? Alors, par expérience, j'ai trouvé ou j'ai énuméré trois cas. Euh donc la livraison partielle, ça veut dire qu'on n'arrive pas à livrer justement la feature pendant l'itération, si on est en sprint ou pendant le temps défini. Et euh, on doit quand même livrer du code parce qu'on n'a pas envie de d'avoir la branche qui euh qui dure dans le temps. Euh, il y a l'activation selon le contexte. Donc on active des fonctionnalités selon des segments, ça peut être la zone, un contexte, un environnement et cetera. Et puis la dépendance externe. La dépendance externe, ça veut dire qu'on a probablement un service à gérer, enfin qu'on utilise en tout cas, ou qui est géré par une autre équipe, donc c'est pas dans notre périmètre et on n'a pas la main dessus. Et donc on va mettre un flipper pour dire bah si euh la le service A tendance à ne pas forcément être up tout le temps, bah je désactive ma feature parce que je dépend de ce service externe. Et donc j'ai posé la question aussi à l'enquête pour essayer de de m'assurer que j'ai bien enfin c'est c'est pas que dans ma tête, on va dire.
[00:11:13] Et effectivement, il y a 29 % du coup qui considère que la feature ne tient jamais sur une itération. Il y a 27 % qui se ce celles qui ont répondu qui utilisent le flip pour activer des fonctionnalités par segment, zone et cetera. Donc par contexte. Et 14 % considère que sont plusieurs à développer en parallèle. Donc euh plusieurs personnes qui travaillent sur la même feature et donc pour ne pas se marcher dessus, on va créer de des flippers. Et ce qui m'a étonné, c'est que il y a 10 % qui considèrent qu'ils testent en prod. C'est lié aussi à on a pas le temps pour les tests. Donc on doit livrer quoi. Mais en tout cas, quand on livre en production, ça veut dire quoi? Ça veut dire qu'on a envie de livrer, on va livrer la feature en désactivée, on va l'activer, et puis on teste en prod et puis si un bug on désactive.
[00:12:10] On va corriger et c'est parti pour la boucle.
[00:12:16] Et donc c'est le le cycle qu'on va utiliser parce qu'on n'a pas le temps de tester, d'avoir une phase potentiellement de de test et donc on va tester directement en prod.
[00:12:29] Mais en tout cas, en plus de ça, grâce à l'enquête, j'ai eu d'autres cas. Euh, d'autres cas, euh j'ai énuméré trois, mais il y en a encore d'autres. Mais les trois principales, c'est le Trunk Based Development, je sais pas si vous connaissez.
[00:12:49] Je je les présenterai juste après. Et puis le deuxième cas, c'est on a un produit qui est en refonte et donc on a l'ancienne version et la nouvelle version et on essaie de de créer des flippers justement pour activer, désactiver en fonction des livraisons et puis euh un cas où c'est une demande explicite du client. J'ai pas mon mot à dire, on m'impose ça et puis euh c'est tout.
[00:13:15] Vous avez d'autres cas, peut-être?
[00:13:19] Non. Donc si je résume, on a d'un côté des cas d'utilisation comme la livraison partielle, l'activation selon contexte, la dépendance externe et cetera mais aussi derrière on a des inconvénients de tout ce qui est feature flipping. Les aucun flipper supprimé, les multitude des if dans le code, donc le code n'est pas illisible, le coût supplémentaire d'analyse et cetera. Et donc c'est pour ça que je vous invite aujourd'hui à euh voir les choses autrement et se poser réellement finalement la question, est-ce que j'ai besoin de ce feature flip là ou pas? Et donc je vais euh tout le long du talk, il y aura plusieurs alternatives, il y aura et de l'organisationnel, priorisation, du design aussi et cetera. Donc je vais commencer par justement le Trunk Based Development. Euh je vous ai posé la question, est-ce que vous connaissez ou pas? Qui connaît? Ah, quand même, pas mal. Est-ce que vous l'utilisez tous les jours ou juste une connaissance qui l'utilise tous les jours?
[00:14:27] OK, 4, 5 personnes.
[00:14:31] Euh qu'est-ce que c'est euh pour celles et ceux qui connaissent pas, finalement, c'est une approche de développement qui va euh inviter en tout cas à contribuer directement sur un tronc commun. Donc on n'a pas de branche. Tout le monde développe sur le la branche main, on va dire. La branche unique et c'est elle qui va être déployée à chaque fois. L'avantage, c'est quoi? C'est que d'une, on a une collaboration continue. Donc les développeurs et les développeuses travaillent ensemble et donc ça favorise forcément la communication et la collaboration entre les membres de l'équipe.
[00:15:05] Euh, on n'a pas besoin du coup de séparer enfin, on a en tout cas l'information de tout ce qui se passe sur le projet. On n'est pas en silo plusieurs équipes chacun à part. Euh, deuxième avantage, c'est que ça réduit les conflits. Euh moins du moins lié au on verra après quand on a plusieurs branches. Mais en tout cas, ça réduit drastiquement le nombre de conflits qu'on va avoir. Puisqu'on est tout le temps à jour finalement. Et puis euh ça ça favorise aussi l'intégration continue puisqu'elle est facilité euh naturellement puisque les devs développent directement sur le tronc commun. Et donc il y a pas de différence ma branche est vieille et il faudra la mettre à jour avant de merger ma branche sur le sur le main.
[00:15:58] Et après, il y a la rapidité du déploiement. Il y a pas besoin de sortir une branche release pour ceux qui utilisent du Gitflow par exemple, à quel moment je vais enfin déployer et cetera. Je sais que le dernier comique est fait, hop, je livre ça. Vous l'avez compris, le Trunk-based development, c'est ça arrive en réaction du branch-based development que potentiellement vous connaissez. Qui est tout simplement, je crée une branche par feature. Donc j'ai ma branche main là et euh à partir du moment où je crée une nouvelle feature, je crée une branche.
[00:16:38] Et euh finalement, ça arrive où euh à certains moments, au moment du merge, j'ai des conflits.
[00:16:45] Donc euh qu'il faudra bien sûr les mettre à les gérer et cetera. Chose qui arrive rarement quand on fait du trunk-based.
[00:16:55] Euh donc voilà. Je disais le Trunk Base Development, c'est en réaction par rapport au base branch based development.
[00:17:06] Et euh il y a une question qui se pose parce que si je suis en trunk base, bah comment ça se passe pour livrer ma feature B alors que j'ai je l'ai pas fini? Donc là, je le le cadran, on va dire violet euh que je release, en fait ma feature B, elle est pas complète, donc elle est pas forcément déployable en l'état. Et c'est comme ça que souvent on associe le feature flipping au Trunk-based development.
[00:17:28] en tout cas, parce que justement l'idée c'est de livrer la branche, enfin la feature B en off jusqu'à ce qu'elle soit fini. Finalement, le Trunk Based Development, ce qu'on va faire, c'est qu'on va livrer, enfin activer uniquement une fois notre feature.
[00:17:51] Donc elle sera désactivée, désactivée, désactivée jusqu'au moment où on est prêt pour la livrer, enfin pour qu'elle soit en tout cas utilisable et là on l'active tout le temps. Sauf que, rappelons-nous. Tu garderas la question pour la fin?
[00:18:08] Euh, rappelons-nous ce qu'on s'est dit, c'est que normalement le feature flipping c'est pour une activation multiple. Donc en fait, là, on n'est pas en train de réellement utiliser le feature flipping tel que il était conçu à la base. Et euh celles et ceux qui utilisent du Trunk-based avec du feature flipping, bah en fait, ils sont ils sont en train ou elles sont en train de faire du branch-based déguisé. Parce que c'est la même chose.
[00:18:39] Euh pour la livraison partielle, est-ce que justement, c'est un des cas qui vous pousse à le faire aujourd'hui? Le à utiliser le feature flipping? Qui euh qui utilise enfin en tout cas utilise le feature flipping pour des livraisons partielles de feature? Ouais, quelques-uns. OK. Le but de la livraison partielle, c'est que c'est derrière il y a un besoin de rassurer. De rassurer les clients, de rassurer le management, de rassurer euh enfin de se rassurer nous-même. Pour dire que on est en train de développer quelque chose. On n'est pas juste en mode effet tunnel où on développe pendant un mois, deux mois pour finalement livrer quelque chose.
[00:19:25] Et surtout, ça permet de réduire les euh le life cycle des des branches. Donc l'idée, c'est euh j'essaie, je ne garde pas une branche active pendant 2 mois parce que la feature n'est pas fini. pour des livraisons partielles de feature. Oui, quelques-uns. OK.
[00:18:59] Le but de la livraison partielle, c'est que c'est derrière, il y a un besoin de rassurer, de rassurer les clients, de rassurer le management, de rassurer, enfin, de se rassurer nous-mêmes. Pour dire que on est en train de développer quelque chose. On n'est pas juste en mode effet tunnel où on développe pendant un mois, 2 mois pour finalement livrer quelque chose. Et surtout ça permet de réduire les le life cycle des des branches. Donc l'idée c'est j'essaie, je ne garde pas une branche active pendant 2 mois parce que la feature n'est pas fini.
[00:19:37] Et donc la question qui se pose, c'est quand on est en sprint par exemple. Donc on on a envie de livrer, on a des features notamment celle-là qui qui est sur deux sprint. Je je me pose la question, est-ce que ce lot d'US n'est pas livrable en l'état ? Et souvent la réponse est on attend la fin de la feature pour livrer la feature entièrement.
[00:20:05] Et là, on revient à des caractéristiques ou des critères que vous connaissez, Invest. Je vais pas les énumérer parce que je considère que vous qui ne connaît pas d'ailleurs ? Ah ben voilà, je je m'en je m'en doutais. Personne.
[00:20:21] Mais c'est surtout moi ce qui m'a ce qui m'intéresse dans ces critères là, c'est la partie indépendante et valuable. En fait, on oublie que euh justement une US quand on va l'écrire, il faut qu'elle soit valuable pour les utilisateurs. Si elle l'est pas, c'est que le split n'est pas forcément bien fait. Du moins euh peut-être on peut splitter autrement. Et d'ailleurs, il y a euh Richard Lorenz et Peter Green qui ont créé un espèce de de de graphe, on va dire, de des différents types de split qu'on peut appliquer. Je ne sais pas si vous l'avez déjà vu, qui l'a déjà vu ce graphe là ? Cool. L'idée c'est vraiment de de dire je peux splitter différemment mes US et j'essaie de voir dans quel cas je suis. Pour mieux splitter les la feature. Et si vous considérez que c'est ce ce type de split là, c'est un petit peu compliqué et c'est compliqué pour et pour les équipes enfin pour le PO ou la PO et pour l'équipe de Dev. Il y a une autre technique plus simple qui s'appelle le hamburger technique.
[00:21:32] qui enfin qui consiste en en disant bah il y a il y a le top qui est la starting point donc le main goal. Euh la viande ou le steak si on est en sandwich, en burger végétarien, disons. Donc c'est l'accord functionality. Et après tout ce qui est des détails d'un plan et cetera, c'est les ingrédients qu'on va ajouter les les comment dire. la salade le fromage et cetera. Et puis à la fin, c'est le endpoint pour le bottom bun.
[00:22:07] Et là si on respecte à la fois le invest, on split correctement nos features, en fait tout ce qu'on va livrer dans la journée, dans les deux jours, bah ça sera livrable en l'état. Et donc on n'a pas besoin de feature flipping dans ce cas-là.
[00:22:23] Un autre cas, c'est l'activation selon contexte.
[00:22:28] Est-ce que vous en avez déjà utilisé, est-ce que vous avez déjà Oui, deux, trois. Oui, quelques-uns. Qu'est-ce que c'est que l'activation par contexte ? C'est par exemple, je veux activer pendant la période de Noël une feature. Je veux activer pour la France et l'Espagne uniquement par rapport au reste des pays. Euh je veux activer cette feature pour l'environnement de développement mais pas pour les autres environnements. Euh je veux activer euh je prends le cas de la B testing pour un certain nombre, un échantillon d'utilisateur. Et là, la question qui se pose, c'est est-ce que on a besoin d'activer ces features là manuellement ?
[00:23:11] Est-ce que c'est pas des critères finalement de métier dynamique ? Oui. Moi je quand je vois ça, je je me dis c'est métier. Il y a pas besoin d'un interrupteur pour éteindre ou allumer la lumière quoi. Et en fait, dans ce cas-là, on est dans un cas de d'un espèce de si on le représente un diagramme d'activité, on a des traitements, on a une condition qui correspond, enfin qui nous dit en fait, on va utiliser un traitement qui correspond à la au qui satisfait les conditions ou alors l'autre l'autre case. Et dans ce cas-là, pour les dev, en tout cas. On peut remplacer tout simplement les flippers par le design pattern stratégie, notamment. Et euh on va dire, bah, on va créer tout simplement, on a une implémentation de notre, enfin notre traitement initial, qui va dépendre d'une interface. Et l'interface sera implémentée par deux implémentations, le cas qui correspond à la condition, enfin qui correspond qui satisfait la condition, et l'autre cas qui ne satisfait pas la la condition. Ça c'est pour le cas simple. Mais on peut aussi avoir des cas plus complexes. Comme une gestion de campagne. J'ai déjà vu des feature flippers, enfin des feature flippers oui pour activer des fonctionnalités par rapport à la période de solde. ou par rapport à la période de Noël ou ou même pour le paiement si jamais j'ai plusieurs types de paiement, euh où je veux combiner plusieurs types de paiement. genre je paye à la fois une partie avec les cartes cadeaux et sur plusieurs fois, bah on avait des feature flippers pour ça. Mais en fait, ça aussi c'est un cas plutôt métier. Et donc c'est pas forcément des feature flipper manuel qui vont les gérer. Il y a une citation de Cyril Mercer qui disait si c'est trop important, enfin si c'est une feature en tout cas, c'est c'est c'est une feature et n'utilisez pas des flaps pour ça.
[00:25:14] Donc euh selon le contexte, si c'est euh si c'est quand on est en mode d'activation selon contexte. Si c'est une nouvelle feature, c'est probablement euh enfin il faut se poser la question est-ce qu'elle n'est pas euh une sorte de sous-domaine au sens DDD du terme, domain driven design ? Est-ce qu'on n'est pas en train de je prends le paiement, c'est souvent peut-être un sous-domaine à part ? Est-ce que je peux pas utiliser, je peux pas remplacer le feature flipping que je vais faire par un pattern, un design pattern du Gang of Four ? et cetera, type stratégie, décorateur ou autre. Et là encore, du coup, on a pas besoin de feature flipper.
[00:25:57] Je reprends maintenant l'autre cas, les deux versions en parallèle. Vous allez me détester, je suis en train de détruire tous les
[00:26:07] Est-ce que vous avez déjà eu ce cas-là ?
[00:26:11] Oui. Pas beaucoup. OK. Là encore, on est dans un contexte de ce qu'on appelle deal with legacy. C'est qu'on a un legacy qu'on est en train de refondre potentiellement ou de retransformer. Et on peut avoir plusieurs façons, soit une réécriture partielle, une réécriture peut-être complète, une extraction partielle de notre code pour le remettre ailleurs. En tout cas, tout ça, il y a plein de techniques justement, enfin, j'ai dit Aroa est un centre de formation donc je je profite pour faire de la pub, on a une formation signature qui s'appelle Pragmatique Archie. Euh où on on présente toutes les techniques pour gérer justement les euh le legacy et comment s'en sortir quand on a un gros legacy qu'on veut refondre.
[00:27:00] Et une ou deux techniques qu'on présente, c'est le Strangler Application Pattern et ce qu'on appelle la technique de branch by abstraction. Alors euh le Strangler Application Pattern ou euh ce qu'on appelle aussi ça vient de de l'image des Strangler Figues qui sont des figuiers étrangleurs, je sais pas si vous connaissez. C'est des plantes qui euh comment dire, qui poussent autour d'un arbre hot et qui l'étrangle, en fait, elles prennent toute l'énergie de l'arbre jusqu'à ce qu'il meure.
[00:27:41] C'est moche, mais on peut l'utiliser dans notre quotidien de dev. Et l'idée c'est de créer justement la nouvelle application et on va pas gérer le legacy et on va considérer que toutes les refontes qu'on va faire petit à petit, en fait, on va les faire directement dans le nouveau code. Et comme ça, le legacy rétrécit et plus on on migre de une feature, on la supprime directement, on ne laisse pas le choix du feature flipper clairement. Et comme ça le legacy rétrécit, rétrécit jusqu'à disparaître. C'est un peu l'idée.
[00:28:18] De l'autre côté, la deuxième technique dont je parlais, c'est branch by abstraction, donc encore une autre technique qui permet là d'apporter des modifications à grande échelle. Euh c'est Martin Fowler qui qui en a parlé et comment ça marche. Euh en fait, on a par exemple des clients qui utilisent le legacy qu'on a envie de remplacer. Donc on va créer une espèce d'abstraction qu'on va router un client pour tester et l'abstraction elle est implémentée par notre legacy donc. Et si tout va bien, on reroute tous les clients sur cette abstraction. Et ensuite, euh on va créer la nouvelle version qui implémente cette cette même abstraction qu'on va tester sur un client et si tout va bien, hop, on bascule tout le monde dessus. Et comme ça, on n'a plus de legacy. Et on fait ça sur petit à petit sur les features et c'est un un peu le même effet que le Strangler Up, c'est que petit à petit le legacy disparaît.
[00:29:21] Donc en fait pour les deux versions en parallèle, on va avoir effectivement les deux show de comment je deal avec le legacy via les patterns et les techniques comme le Strangler Up pattern et la branch by abstraction.
[00:29:40] Et encore une fois, donc, vous la voyez venir, j'ai pas besoin de future flipper.
[00:29:52] Un autre cas, les dépendances externes.
[00:29:57] Est-ce que vous en avez besoin, vous l'avez utilisé ? Est-ce que vous avez déjà eu le cas ? J'imagine que oui. Oui.
[00:30:06] On a souvent besoin d'une dépendance externe. Qu'est-ce que c'est ? Donc c'est un service dont on a besoin mais qui n'est pas dans notre périmètre. Donc c'est un service de paiement par exemple ou alors une API qu'on appelle d'un fournisseur ou enfin ça peut être plein plein de cas. Euh là un service aussi de publication d'actualité par exemple. Et là, qu'est-ce qui se passe ? On a souvent tendance à vouloir appliquer le feature flip. pour ou à cause de manque de confiance de la disponibilité surtout de ce service là. Donc on n'a pas vraiment confiance en ce service, donc je vais mettre un un flipper pour vérifier, enfin si j'ai un bug de prod, hop, je désactive directement. Mais là, je vous propose plutôt une autre technique.
[00:30:56] qui s'appelle le circuit breaker. C'est comme le disjoncteur à la maison, c'est quand il y a un court-circuit, hop, ça disjoncte tout seul.
[00:31:06] Il y a pas besoin de que vous allez dans le boîtier électrique pour désactiver toute l'électricité de la maison. On est d'accord ? Bah là aussi c'est pareil. Et en fait, le circuit breaker c'est quoi ? C'est à la fois un health check, donc il vérifie que le service est toujours disponible et s'il y a le moindre problème, si mon health check n'est n'est pas bon, bah là je hop, je désactive automatiquement. Donc c'est une sorte de combinaison entre le health check et le feature flipping. Automatique, encore une fois, pas manuel. Et là, effectivement, si on arrive à implémenter ça, on est tranquille. On gère automatiquement, il y a pas besoin de surveillance humaine, on va dire par rapport à à ce point-là.
[00:31:53] Maintenant, il y a le cas de la demande explicite du client. Qu'est-ce qu'on va faire pour lui ? Vous avez déjà eu ce cas-là ? Qui a enfin qui s'est retrouvé en mode imposé le feature flipping. Ah bah pas beaucoup, ça va.
[00:32:12] Donc dans ce cas-là, effectivement la personne ou enfin il ou elle potentiellement qu'elle a pas compris l'utilisation ou l'usage des feature flippers. Et là, je vais faire un petit peu de pub, n'hésitez pas à lui présenter cette présentation.
[00:32:29] Euh voilà voilà, donc pour résumer, en fait, le feature flipping pour moi, c'est une question. enfin c'est une solution de facilité plutôt, une facilité pour dire ah, si j'ai besoin, au moins c'est c'est mon côté assurance pour me dire je désactive au moment où il y a un problème. Une une solution de facilité parce que j'ai pas besoin effectivement euh de de de m'occuper en tout cas de trouver une autre solution. Mais euh il faut se dire que cette solution de facilité là, elle est utile à court terme, mais il faut être conscient et consciente qu'à long terme, ça sera pas forcément payant parce que il y a tous ces inconvénients là qu'on a vu au début. C'est que le code, il devient de plus en plus difficile à maintenir. Euh le coût supplémentaire d'analyse qu'on va devoir gérer pour vérifier que tout enfin si on rajoute un flipper que ça marche toujours bien avec l'existant et donc ça veut dire des non-régression plus longues, des tests de non-règle plus longs ou du moins parfois des campagnes même de tests de non-règles. Et surtout le le pire, c'est le turnover dans les équipes parce que si les devs ne sont pas contents et contente de ce qui se passe, de l'environnement technique, bah ils vont pas rester.
[00:33:52] Et donc comme on a vu, il y a beaucoup de d'alternatives justement par rapport à ça et les solutions sont multiples que ce soit par par rapport à un meilleur split. les design pattern, ils sont pas là pour faire joli, on peut les utiliser.
[00:34:09] Euh domain driven design, pareil. Euh si on décompose correctement les domaines et les sous-domaines, on peut s'en sortir mieux en identifiant les features dans quel domaine c'est et il y aura plus besoin. et puis des patterns pour gérer les legacy, le Strangler app ou alors le branch by abstraction. Et dans le cas ultime, un circuit breaker, ça fera très bien l'affaire à la place d'une activation ou désactivation manuelle des feature flipping. Voilà, si vous avez envie de continuer à participer à l'enquête, n'hésitez pas, ça me fera encore plaisir pour avoir des avis encore plus que ceux qu'on a qu'on que j'ai eu jusque là. Et euh je vous dis merci.
[00:35:01] Je ne sais pas s'il y a des questions. Tout à l'heure, oui.
[00:35:07] Oui, là. Pardon.
[00:35:20] 1 2 3 1. En fait, ma question de tout à l'heure, c'était sur le le trunk based development où je me disais euh pour pas avoir l'habitude de de fonctionner sur ce type de de flow Git, je me disais où est-ce qu'on fait les les revues de code, contrairement aux demandes de MR qu'on pourrait avoir avec du branch based development ?
[00:35:40] Bah souvent le trunk based development, ça vient aussi avec du pair ou du mob programming. Quand on fait et donc la revue de code, on en a plus besoin, on le fait naturellement au cours du développement.
[00:35:53] Très bien, merci.
[00:35:57] Il y en a une là.
[00:36:02] Alors merci beaucoup pour ce talk, c'était super intéressant.
[00:36:07] Je suis en plein dans le sujet parce qu'on est en train de voir pour implémenter du trunk base, forcément les future flag, tout le monde en parle, c'est un gros débat et des fois on l'utilise bien, des fois pas bien, il y a des cas où je me suis dit ah oui là en effet, on aurait dû faire différemment. Donc c'est ça me donne de nouvelles idées, donc c'est super cool.
[00:36:22] Par contre, j'ai aussi l'impression que les future flag les gens sont attachés à ça parce que aujourd'hui il y a des SAS qui fournissent des future flag avec les gens même non-tech qui sont autonomes pour définir leur flag, définir les conditions des flag, les activer, les désactiver et il y a des équipes aussi avec des gens du produit et cetera qui sont j'ai l'impression aussi attachés à ça à le fait de pas avoir à passer par l'équipe de développement pour changer une condition d'un flag existant, en disant bah non non, c'est plus 2 % des utilisateurs, c'est 5 % ou bien je change le pays ou bien et cetera et cetera. Je sais pas si tu as eu des retours aussi sur ça sur le fait que beaucoup de systèmes de feature flag en fait donnent aussi l'autonomie de créer et customiser les flags à des équipes qui ne font pas partie, on va dire de enfin qui sont pas techniques en fait, qui ensuite ont l'autonomie sur ça. Merci.
[00:37:07] Effectivement, souvent les feature flags sont enfin l'activation en tout cas et la désactivation est faite directement par les PO. Et ça aussi, enfin en tout cas, moi ce que je conseille souvent, c'est de dire au lieu d'arriver au moment où pourquoi on a besoin d'activer et désactiver, c'est qu'il y a un manque de confiance aussi.
[00:37:28] C'est vrai.
[00:37:28] C'est c'est ça. Et donc au lieu d'arriver jusque là et dire j'ai besoin de cette assurance là pour me garantir que tout fonctionne, bah travaillons en amont, le split des US, la priorisation et est-ce que justement le pourquoi des des choses, la vision du produit. Et là, tout de suite, on on change du coup le cap, il y aura plus besoin de feature flipping.
[00:37:52] Oui, c'est vrai, le manque de confiance, c'est un vrai truc, c'est un vrai sujet. Merci.
[00:37:57] Il y en a une là.
[00:38:01] Merci. Euh bonjour et merci pour la présentation. Euh moi j'ai une question, est-ce que pour toi, quand tu qualifies une feature flag ou flipping, euh ça concerne que l'environnement de prod ou euh même avant en fait, les environnements de de dev, de recette et cetera ? Parce que souvent on est amené à faire des US euh bouchonnés pour qu'on puisse avancer, pour qu'on n'attend pas la livraison d'une autre US, d'une autre squad et du coup, euh mais ça reste avant l'environnement de prod. Donc ma question, voilà, est-ce que ça concerne pour toi tout environnement euh au-delà de de l'environnement de prod. Et est-ce que les US bouchonnés pour toi euh ça représente des des feature flipping ?
[00:38:47] J'entends deux questions dans une même. Alors, est-ce que les feature flipping c'est uniquement pour l'environnement de prod ? Non, parce qu'on peut très bien avoir des feature flippers pour les environnement dev et il y en a même justement le cas d'activation par contexte, on peut très bien avoir une feature qui est activée dans l'environnement de développement et pas dans l'environnement prod par exemple, parce que justement c'est un cas de bouchon d'un service externe qu'on a pas envie qui n'a qui ne propose pas un environnement de dev notamment. Donc il y a il y a ce cas-là, effectivement, mais là, pareil, si on utilise le pattern stratégie, on peut dire que dans l'environnement de prod, on utilise l'implémentation de prod et dans l'environnement de dev, on utilise l'environnement, enfin la partie, enfin l'implémentation qui correspond au dev et tout de suite, c'est côté IO aussi, enfin l'inversion of control qui se gère. Et donc dans l'environnement de prod, je récupère la telle implémentation qui est le bouchon et dans l'environnement de prod, je récupère l'instance réelle. Ça peut se gérer aussi par les patterns quoi, c'est ça mon point et donc on n'a pas besoin de flipper. d'un service externe qu'on a pas envie qui n'a qui ne propose pas un environnement de dev notamment. Donc il y a il y a ce cas-là, effectivement. Mais là, pareil, si on utilise le pattern de stratégie, on peut dire que dans l'environnement de prod, on utilise l'implémentation de prod, et dans l'environnement de dev, on utilise l'environ enfin la partie, enfin l'implémentation qui correspond au dev. Et tout de suite, c'est côté IOC, enfin l'inversion of control qui ça soit géré.
[00:39:41] Et donc dans l'environnement de prod, je récupère telle implémentation qui est le bouchon. Et dans l'environnement de prod, je récupère l'instance réelle. Ça peut se gérer aussi par les patterns quoi. C'est c'est mon point. Et donc on a pas besoin de flipper.
[00:39:59] Juste derrière.
[00:40:01] Je voulais déjà merci pour la présentation. Je voulais rebondir justement sur cette question-là. Il y a une histoire de coût, surtout en en développement, en environnement développement, on n'a pas envie de se prendre la tête à faire des solutions qui sont plus coûteuses en temps, sachant qu'on sait très bien qu'on va les supprimer juste avant que ça parte enfin. Des fois enfin là, c'était en pro dev, mais des choses qu'on fait qu'en dev. Donc voilà, il y a une histoire de coût. En fait, on n'a pas eu, enfin, vous n'avez pas du tout parler de l'histoire de coût sur le fait de mettre en place certaines méthodes. Sachant qu'il y a certains clients qui m'ont clairement dit que c'était pas grave, c'était du carton. Qu'est-ce que voilà, quelle est la solution à minima qu'on peut mettre en place ?
[00:40:43] Juste une question avant que je réponde pour pour savoir si j'ai bien compris. La question du coup, c'est par rapport à quoi ? Par rapport à l'utilisation des flippers ou par rapport à l'implémentation, j'en je crée, enfin j'utilise un pattern ?
[00:40:57] C'est c'est l'utilisation des flippers. Des fois, j'ai l'impression qu'on a pas le choix. Et euh à quel moment, en fait, ça vaut le coup de dépenser de l'argent pour mettre en place, on va dire, voilà, se dire, on met des design patterns, on réfléchit vraiment à à bien découper les US et cetera, parce que c'est quand même du temps, euh pour peut-être quelque chose qui est jetable.
[00:41:19] Hmm.
[00:41:22] Dans ce cas-là, euh bah déjà, si c'est jetable, est-ce que ça sera pas un poc? Enfin, c'est dans le sens là, si c'est jetable.
[00:41:32] Ce serait dans un monde idéal.
[00:41:36] Là, c'est pareil, c'est euh, c'est en amont, on réfléchit de qu'est-ce qu'on va faire, est-ce que c'est un POC ? Dans ce cas-là, est-ce que ça mériterait pas du coup d'être carrément indépendant de l'application qu'on a en cours, de de la déployer ailleurs ? Pas forcément dans un environnement de dev ou du AT pour justement tester ce POC là. C'est la première solution. Et ça coûte pas cher, enfin, ça coûte pas cher. Ça coûte le coût de l'environnement qu'on veut créer à part. C'est ça ce qui va coûter potentiellement, si on fait ça. Ensuite. L'implémentation des patterns, ça coûte pas si cher par rapport au aux librairies ou au coût euh aux conséquences en tout cas des flippers qu'on va utiliser. C'est ça ce qu'il faut se dire. C'est que aujourd'hui, effectivement, on a l'impression de faire un flag ou un flip, un flipper, ça coûte pas cher. Mais derrière, potentiellement, est-ce que la gestion de ces flippers là, est-ce qu'on l'a fait maison ? Donc il faudra créer tous les cas possibles. Est-ce qu'on va utiliser une librairie qui gère les flippers ?
[00:42:38] Bah là, on rajoute une dépendance à notre projet potentiellement qui n'est pas utile. Et euh en parallèle de ça, faire un espèce un un pattern stratégie tout quand avec juste une interface et deux implémentations, je pense pas que ça coûte très cher. Donc c'est c'est un choix, mais enfin, je suis intimement convaincue que le feature flipping, c'est plutôt une solution de facilité. J'on n'a pas envie de réfléchir, on n'a pas envie de se prendre la tête, et donc on va utiliser la la solution la plus simple. À l'an santé, mais qui a de conséquences graves à T + 1.
[00:43:14] Merci beaucoup.
[00:43:16] De rien. Il y a une question au milieu, juste derrière.
[00:43:24] Euh, merci beaucoup, Daria. Euh, je voulais savoir, donc là, tu nous as donné beaucoup de cas où on ne devrait pas utiliser les les feature flipping.
[00:43:33] En tout cas, euh tu avais dit aussi que c'était un smell. Est-ce que tu vois, ne serait-ce que un cas, ou quelques cas, où euh ça pourrait être utile ?
[00:43:47] Le seul cas que je vois, c'est celui-là. Et pas que le feature flipping seul. C'est euh on essaie de d'automatiser. En fait, le mon mon point, c'est à la fois euh l'utilisation des librairies de feature flipping ou des frameworks de feature flipping, mais aussi le côté manuel qui m'embête. C'est que ça veut dire que on réagit à un bug ou on réagit, on arrive trop tard en fait. C'est que le le mal est fait entre guillemets. Alors que si on fait un health check par exemple ou euh des tests minimalistes pour vérifier que tout l'environnement est euh OK et avoir un feature flipping automatique, là ça me va. C'est juste le côté manuel qui me mérite. Merci beaucoup. Je sais pas si je réponds à ta question du coup.
[00:44:38] Euh, oui, euh, précis, si je peux continuer, en fait, moi, je l'utilise beaucoup avec le TBD. Par contre, à bon d'édition, c'est-à-dire qu'il y en a pas partout. Il y a un très peu là où on en a vraiment besoin. Euh, je trouve que dans certains cas pour le TBD, pour quand on n'arrive pas à découper euh correctement ou que le client ne veut pas sa bout de futur tout de suite euh avant que d'autres parties de la future soient terminées et cetera. Euh, des fois, je le vois un avantage quand même. Donc c'était pour savoir si tu avais aussi une expérience un peu similaire ou pas.
[00:45:09] Alors euh, j'ai pas encore vu un mais ça veut pas dire que ça n'existe pas, peut-être ça peut-être ça existe, mais en tout cas, j'ai pas encore vu de de use case qui mériterait vraiment un du future flipping.
[00:45:25] Merci beaucoup.
[00:45:33] Eh ben.
[00:45:37] Merci. Un des cas que tu avais évoqué, c'était la partie euh test AB, notamment. Euh là, comment tu le vois sans le feature flipping, ou alors est-ce que c'est un abus de de naming de de parler de test AB feature flipping ?
[00:45:54] Est-ce que c'est un euh je j'essaie de reformuler ta question, est-ce que le feature flipping, c'est un abus pour l'AB testing, c'est ça ?
[00:46:01] Oui.
[00:46:04] En fait, quand la l'AB testing est fait maison, euh souvent on enfin, je sais pas dans quel, est-ce que tu l'as déjà utilisé ?
[00:46:13] Déjà la la partie AB testing. Mise en place sur du coup des éléments de front, à la fois sur de la conversion, par exemple, en e-commerce, et après sur tester deux UX.
[00:46:23] Et on voulait on voulait le déployer. Et juste pour finir la question sur notamment sur la partie UX.
[00:46:29] On s'est dit qu'on allait plutôt être dans une démarche de c'est pas forcément même Canary, c'est-à-dire de livrer progressivement et pas tous les clients en même temps. Et donc c'est pas de la B testing, mais c'est plutôt du Canary en fait qu'on a mis en place. OK.
[00:46:43] En fait, la question euh qui se pose, c'est est-ce que euh la B enfin, l'AB testing, c'est quoi ? C'est euh je prends un échantillon d'utilisateur et je les redirige vers euh un une version. Euh, et je garde tous les autres. Enfin, si j'ai deux versions, après si j'ai plusieurs, j'ai j'échantillonne. Et la la question euh qui se pose, c'est est-ce que l'échantillonnage que je fais, est-ce que enfin, c'est quoi la règle pour identifier cet échantillon cet échantillonnage là ?
[00:47:11] Est-ce que c'est le nombre ? Est-ce que c'est un profil particulier d'utilisateur ? Et en fait, c'est ça la question, c'est quel est mon critère ? Si c'est un critère métier, bah dans ce cas-là, c'est pas du feature flipping. C'est plutôt des justement des critères métiers et euh ça veut dire que j'ai un choix de enfin si mon utilisateur correspond à ses critères-là, je le redirige vers là.
[00:47:35] On n'est pas forcément dans le feature flipping.
[00:47:40] Dans d'autres cas, peut-être que si c'est un espèce enfin le c'est le nombre, je prends les 10 premiers, les 10 derniers. Bah pareil, en quelque sorte, c'est euh, j'ai mes utilisateurs et je les redirige euh. En fait, si tu le si tu veux l'implémenter de façon à utiliser du feature flipping, ça veut dire quoi ? Ça veut dire que c'est pas un flipper que tu vas utiliser, c'est plusieurs.
[00:48:05] Donc on est d'accord, c'est à dire que l'AB testing, c'est un autre sujet. C'est on peut, ce n'est pas le feature flipping.
[00:48:11] Oui, oui, clairement oui.
[00:48:19] Tu veux de la marche de la journée ? Merci.
[00:48:26] Merci. Euh, moi ma question, c'est pour être sûr de si on devait synthétiser en une phrase au final ce que tu dis, c'est qu'il faut éviter de d'activer manuellement, mais que ça soit fait automatiquement au final. Si je comprends bien, c'est ça la différence que tu fais entre le feature flag qui est manuel et tout le reste, tout ce que tu présentes est finalement, il faut que ça soit fait automatiquement d'une manière ou d'une autre. Est-ce que c'est ça ?
[00:48:49] Plus que ça. C'est que ce que ce que je vous invite vraiment à dire, c'est que si jamais vous avez besoin de feature flipping, c'est posez-vous la question, est-ce quel est mon use case déjà? Si j'ai euh je suis dans un un des des cas d'utilisation que j'ai mis euh je reprends la slide, hop, celle-là. En gros, si je suis dans un des use case vraiment les enfin les tous les use case à part la dépendance externe, bah en fait, c'est que j'ai pas besoin vraiment de feature flipping. Le seul cas où je sens que il y a un besoin de feature flipping mais automatique, c'est la dépendance externe. Et euh et là je fais du circuit de breaker plutôt qu'un feature flipping classique manuel. C'est ça mon point.
[00:49:36] OK, parce que au final, dans dans tous les cas, il faut toujours une condition quelque part. C'est vu que c'est il y a un chemin qui est choisi, que ça soit choisi statiquement à la compilation, un fichier de conf ou peu importe. Donc les ifs ils existent toujours. Au final, on est d'accord.
[00:49:53] Oui.
[00:49:55] Oui, oui. Alors, ce que là, je parle de feature flipping en utilisant les outils et les librairies de feature flipping. Une condition métier, c'est en quelque sorte un switch hein. Donc c'est un flipper naturel, mais c'est métier, c'est pas technique, c'est une config en base que je sète manuellement. C'est ça la différence.
[00:50:17] OK, donc c'est bien. Merci.
[00:50:21] D'autres questions ?
[00:50:25] Bravo. Merci beaucoup.

Transcription