In May our friends at Algolia opened up their new offices in Paris, France to our Test in Production Meetup. Mikael Krief, DevOps Technical Manager at Cellenza and Microsoft MVP, kicked off the evening with a talk about how we can use feature flags to plan to test in production.
“L’avantage d’avoir un feature flag qui encapsule votre développement c’est que même une fois que c’est mergé tant que la feature flag n’a pas été activée, votre code n’est pas encore utilisé en production. Donc on s’est posé la question si on utilisait ou pas les feature flags et durant cette réflexion on a.”
You can watch Mikael’s talk below, or read the transcript–but being in Paris, Mikael choose to give his talk in French. If you’re interested in joining us at a future Meetup, you can sign up here.
TRANSCRIPT
Bonjour à tous, bienvenu dans cette session appelé implémentation des feature flags. Pour me présenter je suis Mikael Krief, je suis Technical Manager DevOps chez Cellenza. Cellenza pour ce qui ne savent pas est un cabinet de conseil autour des technologies Microsoft, spécialisé Microsoft. Aujourd’hui on essaye un petit peu de s’étendre sur tout ce qui est open source, en tout cas pour la partie DevOps. On fait du .NET, on fait de l’Office, on fait plein de technos qui tournent autour des technologies Microsoft. Je suis MVP, ALM et je fais aussi partir de la communauté des Visual Studio ALM Rangers. On crée tous ce qui est outils et guides de tout ce qui est la partie DevOps Microsoft. Donc c’est open source, on a créé pas mal de produits, pas mal d’articles de blog pour justement aider les utilisateurs, les entreprises à mieux utiliser les outils de Microsoft, notamment VSTS, TFS, Azure aussi un petit peu et on essaye de créer tout ça en temps réel avec l’évolution de ces outils de Microsoft pour aider au mieux les entreprises et les utilisateurs finaux.
Parmi les outils qu’on a créé, on a créé un outil qui est une extension à VSTS. Petite question est-ce qu’il y en a qui savent ce que sais qu’une extension à VSTS ? D’accord, donc VSTS c’est l’usine logiciel on va dire de chez Microsoft, qui est dans un cloud. Ça contient un contrôleur de source, ça contient des builds, release, ça contient un gestionnaire de package, ça contient énormément de choses pour permettre d’avoir votre code, de pouvoir le déployer jusqu’au bout, de le tester, d’avoir un outil complètement dans le cloud qui permet de faire tout ça. Donc une extension à VSTS, je peux vous le montrer très rapidement j’y reviendrai de toute façon après, c’est un petit widget que nous avons créé ici, ça c’est VSTS. On a créé un widget qui permet d’afficher le nombre des éléments qu’il y a dans le kanban, parce que VSTS contient aussi toute une gestion de projet agile dans le kanban et donc on a créé un petit widget comme ça qui permet d’avoir rapidement le nombre d’éléments qu’il y a dans chaque colonne du kanban. Durant le développement de cette extension, une extension c’est tout simple à développer, c’est un outil client donc c’est juste du HTML, CSS, JavaScript. Bien-sûr il faut faire appel aux API de TFS, VSTS mais sinon en soit il n’y a rien de très compliqué c’est un outil purement client.
Durant le développement de cette extension on a eu plein de demandes d’utilisateurs pour ajouter des fonctionnalités, on a commencé à les développer donc on a commencé à créer des branches un petit peu partout, on a créé des branches on voulait les livrer et puis à un moment donné on s’est posé la question et si on commençait un petit peu à implémenter des feature flags ?
Feature flag sa porte un autre nom, si vous cherchez un peu sur le net sa porte aussi le nom “feature toggle”. Ça porte d’ailleurs je crois, plus le nom de feature toggle que feature flag. Ça représente exactement la même chose. Donc en fait ça permet en quelques mots très rapidement de pouvoir isoler un peu vos développements en encapsulant justement tous ces développements dans ce qu’on appelle des features et ainsi de pouvoir les activer ou pas à la demande de l’utilisateur. Ça a un autre avantage c’est que ça va permettre de pouvoir mieux gérer vos branches, vous allez me dire, “Dans ce cas-là pourquoi est-ce qu’on ne continu pas à utiliser des branches ?”. Le problème des branches c’est qu’on n’a souvent tendance à les merger très rapidement, on a peut-être pas fini un développement on a mergé la branche et par erreur ça se retrouve en production. L’avantage d’avoir un feature flag qui encapsule votre développement c’est que même une fois que c’est mergé tant que la feature flag n’a pas été activée, votre code n’est pas encore utilisé en production. Donc on s’est posé la question si on utilisait ou pas les feature flags et durant cette réflexion on a– Je reviens juste sur mes slides.
Pourquoi des feature flags comme je vous le dis c’est pour découpler le déploiement et l’exposition des développements. Ça permet d’avoir un real time control sur les utilisateurs, est-ce que ce n’est pas les utilisateurs, on va pouvoir dire que tel utilisateur finalement à accès à telle fonctionnalité ou pas directement en production. On va pouvoir changer justement une feature, activer une fonctionnalité pour un utilisateur directement en production sans avoir à redévelopper, redéployer la fonctionnalité, l’application. Parce qu’on sait que chaque redéploiement ça peut générer un problème dans l’application. On va pouvoir donc avoir un test et des feedbacks très rapide de l’utilisateurs directement en production et d’expérimentations aussi, et bien-sûr si on se rend compte qu’une fonctionnalité qu’un feature flag ne nous conviens pas parce qu’il y a un bug on peut directement la désactiver directement en production sans avoir à redéployer l’application.
On a réfléchi à quels étaient maintenant les différentes solutions qu’on avait pour pouvoir implémenter les feature flags. Il faut savoir que VSTS par exemple utilise aussi des feature flags, mais ils ont dû développer leur propre système de feature flags. Donc on peut développer son propre système, c’est juste du code, on la tous fait un petit peu pour ceux qui ont fait un peu du développement .NET dans le fichier de config, le web.config d’avoir un pp settings, je mets true or false et puis c’est parti. Donc on peut très bien développer son propre système de feature flags. Il existe aussi plusieurs autres solutions open sources, des frameworks que l’on peut trouver sur le net, open sources. Bien-sûr il faut les tester une par une, il faut les installer parce qu’il y a une base de données derrière, il faut les installer.
Ça demande du temps et d’expérimentation et il existe aussi d’autres systèmes on va dire pass donc cloud donc LaunchDarkly qui est la solution que nous avons retenue d’abord parce qu’elle est simple à utiliser, elle est très simple à utiliser, je vais vous le montrer, mais aussi parce que LaunchDarkly déjà appartenait déjà à Microsoft.
Une fois qu’on a trouvé la solution d’utiliser LaunchDarkly on s’est dit quel allaient être les scénarios d’utilisations finalement de ces feature flags et on avait deux grands scénarios, le premier scénario c’est qu’on avait pas mal de fonctionnalités internes donc par exemple pouvoir afficher des logs dans notre browser. Au départ on les affichait tout le temps et on s’est dit que ça pouvait un petit peu perturber l’utilisateur qui affichait ces logs d’avoir trop de logs justement parfois ça perturbe un peu l’utilisateur. On s’est dit c’était bien si on pouvait le désactiver. Deuxième cas d’utilisation, c’est pour pouvoir avoir d’autres cas de fonctionnalités internes comme par exemple la télémétrie donc avec nous on utilisait l’application Insight, App Insight mais on s’est dit qu’il y a des environnements où on voulait ne pas avoir de télémétries, donc pouvoir désactiver à la demande la télémétrie soit pour un utilisateur soit pour un environnement particulier, et bien-sûr aussi de pouvoir dire à un utilisateur vous choisissez vous-même si vous voulez avoir ou pas la fonctionnalité, et tout ça bien-sûr en production. Je ne parle pas des autres environnements, on est en production. Il faut savoir que VSTS est utilisé par je sais pas combien de milliers d’utilisateurs et que notre extension est installée en tout cas sur plus de six mille ou huit mille comptes VSTS donc sachant que chaque compte a été utilisé par plein d’utilisateurs vous savez que nous avons un fort trafic et donc il fallait pouvoir faire ça bien et correctement pour ne pas générer plus de problèmes sur l’application.
Donc la solution qu’on a retenu comme l’extension VSTS est une full client donc c’est que du HTML, JavaScript et CSS, ce qu’on a fait c’est qu’on a utilisé des Azure fonctions pour pouvoir utiliser le SDK de LaunchDarkly donc on a utilisé le SDK DotNet, qu’on a utilisé dans des Azure fonctions et qui sont appelées par notre extension. L’Azure fonction fait appel au SDK, récupère les informations de LaunchDarkly et les renvoit à l’extension VSTS.
On va un petit peu regarder un petit peu tout ça maintenant concrètement comment ça se présente? Donc on a notre extension ici, le premier élément déjà qu’on voulait c’était de pouvoir éliminer un peu les logs. On n’avait un peu trop de logs. Ici notamment cette ligne là que vous voyez. C’étaient les logs interne à l’extension donc on n’affichait dedans les différentes requêtes qu’on utilisait voilà des différentes colonnes, les requêtes qu’on utilisait. Donc ça c’est bien pour du debug pour nous c’est pour ça qu’on l’avait mis en place. C’est pouvoir debugger à distance si on avait besoin d’un utilisateur qui nous disais “Je comprends pourquoi ça ne marche pas”, on avait les différents logs qui nous permettais de pouvoir debugger rapidement mais c’est vrai que c’est n’était pas souvent indispensable donc on s’est dit le premier cas d’utilisation c’est de pouvoir souvent masquer un peu ces logs à la demande de l’utilisateur.
Donc on a utilisé LaunchDarkly, le Dashboard de LaunchDarkly, le portail est assez simple d’utilisation, vous avez ici une liste de feature flags où il vous suffit rapidement de pouvoir très rapidement créer une feature. Donc chaque feature a un nom, une clé, essayez une description. Vous lui dite si c’est du “oui” ou “non”, “oui” je veux “non” je ne veux pas et je peux utiliser après le SDK il suffit de dire voilà je veux utiliser pour calquer que j’avais– Donc on peut voir que par exemple j’avais créé ici une feature flag qui s’appelle display log donc on l’a activé et on a donc deux variations qui nous dit “oui” ou “non”, je veux ou pas la feature. Par défaut on n’a personne, pour tout le monde c’est “non” et on va laisser les utilisateurs finalement choisir s’ils veulent ou pas les logs. Donc il suffit de sauvegarder donc là pour le moment il n’y a personne. Si je reviens–je vais fermer ça.
Donc on a dans le panel de configuration on a rajouté un petit toggle ici qui permet à l’utilisateur de pouvoir choisir s’il veut ou pas les logs. Voilà par défaut comme j’ai mis personne n’a accès au log donc c’est “off” et il peut choisir lui-même ici en cliquant, voilà. Il faut le faire deux fois la première fois.
La personne veut les logs, il sauvegarde et s’il rafraîchit là au moins il y a les logs. Ici vous avez la ligne, si maintenant je reviens et que je désactive ici.
Voilà vous voyez bien que je n’ai plus la ligne ici que j’avais auparavant. Donc tout ça en production j’ai rien eu besoin de re-livrer j’ai juste besoin à changer une flag, donc pour ça on a utilisé l’API de LaunchDarkly. LaunchDarkly possède des API donc vous avez toute la documentation ici, et cette API en fait permet de pouvoir manipuler comme ça les feature flags pour les utilisateurs. Le deuxième cas de scénario qu’on a utilisé c’était pour activer ou pas le monitoring. Ça par contre c’est une feature ce qu’on appelle interne à nous ça veut dire qu’il y a que nous qui pouvions décider si vous voulez activer ou pas le monitoring pour l’application. Donc pour ça on a utilisé le SDK DotNet. Alors il faut savoir que pour LaunchDarkly il existe des SDK pour tous les langages quasiment. Voilà donc vous pouvez voir ici tous les différents langages. On a utilisé le .NET SDK, très simple à utiliser vous récupérez juste un package en fait et vous initialisez un objet à client avec la clé que vous avez ici dans votre portail.
Voilà vous avez ici un SDK qui est–vous utilisez sous SDK ce qui permet donc d’identifier votre compte et la partie projet dans LaunchDarkly. Vous utilisez ça et après vous pouvez aller dire est-ce que tel utilisateur à accès ou pas à tel fonctionnalité. Voilà c’est très simple à utiliser et la documentation est vraiment très fourni. Voilà vous pouvez customiser les utilisateurs. Alors on n’a dû se renforcer en sécurité surtout avec le GDPR c’est-à-dire qu’on ne pouvait plus rien laisser comme information sensible dans le portail. On a tous mis en termes de clés en tout cas on n’a laissé que des UAD et donc bien-sûr vous pouvez directement à partir du portail dire que cet utilisateur finalement il a accès ou pas à la télémétrie ou au log par exemple.
Donc là directement à partir d’ici je peux si un utilisateur a un problème et qu’il n’arrive pas à désactiver ou pas la fonctionnalité directement à partir du portail on peut lui faire et ça sera pris en compte directement sur l’application. Juste un petit coup d’œil aussi sur les Azure fonctions donc on a développé tout ça avec Visual Studio. Donc on à quelques Azure fonctions ici qui nous permettent de récupérer la liste des flags pour un utilisateur et qui permet d’updater un flag pour un utilisateur. Les étapes maintenant qui nous restent un petit peu à faire c’est on va- ce qu’on va faire c’est un petit peu de l’A/B testing. Donc l’A/B testing c’est ce qui permet un petit peu de comparer une fonctionnalité en prod mais avec deux scénarios différents parce que souvent dès qu’on livre comme ça des fonctionnalités en production on ne sait pas si finalement ça va plaire aux utilisateurs, ça va bien fonctionner. Comment la fonctionnalité va réagir vis-à-vis des utilisateurs.
Donc du coup grâce un petit peu aux feature flags en laissant la fonctionnalité qu’a une certaine population donnée par exemple vous pouvez définir une régions pilote qui va tester votre fonctionnalité, vous allez pouvoir avoir ce qu’on appelle de l’expérimentation et voir qu’il y a 60% des utilisateurs par exemple que vous avez défini qui ont choisi d’activer la fonctionnalité. Ça veut dire que la fonctionnalité est bien, que ça plait et donc vous allez pouvoir l’activer. L’idée maintenant c’est un petit peu via LaunchDarkly, puisque LaunchDarkly permet aussi de faire du LaunchDarkly et voilà grâce aux goals on va pouvoir maintenant voir un petit peu le comportement maintenant que ça fait plus de deux mois qu’on utilise les feature flags maintenant pour avoir un petit peu grâce a ça est-ce que finalement les utilisateurs ont aimé cette fonctionnalité de pouvoir désactiver les logs à distance ou pas.
Voilà et deuxième qu’est-ce qui arrive comme nouvel élément aussi c’est de pouvoir maintenant intégrer ça sur d’autres extensions VSTS puisqu’on a plus d’une dizaine d’extensions qu’on a fait dans notre catalogue. Donc maintenant l’idée c’est de pouvoir implémenter ça sur d’autres extensions. Bien-sûr vous pouvez retrouver tout ça sur notre GitHub, donc dans les GitHub de ALM Rangers. Voilà vous avez un repo Azure fonction VSTS et donc vous avez les Azure fonctions et vous avez l’extension ici. Problème dedans vous allez voir comment on a utilisé justement les feature flags à l’intérieur. Est-ce qu’il y a des questions ? Non, c’est parfait c’est que j’ai été clair. [rire]. Même des questions sur LaunchDarkly je peux essayer ou Andrea peut essayer de répondre. C’est parfait.
.webp)
