All posts in Agile

Les Feature Toggles* : Activer / Désactiver dynamiquement une fonctionnalité d’un logiciel

By Mathilde Salthun-Lassalle / 13 janvier 2019 / 3 Comments

* La désignation ne fait pas consensus et la liste des termes synonymes est très longue : Feature Flag, Feature Switch, Conditional Feature, Feature flipper, Feature Bits, Gatekeepers….

Le principe

À la livraison d’une nouvelle version d’un logiciel sur un environnement, toutes les nouvelles fonctionnalités sont rendues disponibles immédiatement. Au contraire, le modèle de design Feature Toggle* a pour but de fournir un interrupteur de fonctionnalités qui active ou désactive une partie du code sans nécessiter ni redéploiement ni redémarrage de l’application.

Les usages possibles

Cette fonctionnalité peut avoir de nombreux usages. Les cas suivants en sont un exemple et ne représentent pas l’exhaustivité des situations.

CAS 1 – Différents besoins sur différents environnements

Pratiquer des livraisons régulières, fréquentes et de petite taille est une des conditions à garantir pour l’agilité d’un projet (Continuous Delivery). L’enjeu est le maintien d’un cycle de développement court pour limiter les risques du rythme élevé de changements. Or si cette stratégie s’avère un atout en environnement de recette, où la validation de petites briques logicielles réduit la durée de la phase de tests, elle peut être difficile à réaliser en environnement de production. En effet, une fonctionnalité peut représenter plusieurs itérations de développements et il serait incongru de la mettre à disposition de l’utilisateur de façon incomplète. Le système de feature toggles rend possible la livraison de parties de fonctionnalités en mode désactivé sans que cela n’affecte la stabilité du code. L’activation pourra être réalisée au bout de quelques semaines, une fois que l’ensemble du code nécessaire aura été livré.

CAS 2 – Incident suite à une livraison

Lorsqu’un dysfonctionnement est rencontré en production par un utilisateur suite à une récente livraison, il sera possible de désactiver la fonctionnalité pour réduire l’instabilité du logiciel en attendant une résolution.

CAS 3 – Dépendances entre équipes

Il n’est pas rare que plusieurs équipes travaillent en parallèle sur des besoins différents et dans des délais qui leur sont propres tout en ayant en commun une ou plusieurs applications. Par exemple, l’interface peut être la même pour toutes les équipes. Lorsque le moment est venu pour une équipe de livrer son travail, elle se trouve gênée par les développements encore en cours ou en validation des autres équipes sur l’application partagée. Si chaque équipe a mis en place des toggles,  la livraison sera envisageable à la condition que chaque fonctionnalité non encore terminée soit désactivée.

CAS 4 – Tests comparatifs

Il existe une catégorie de Feature toggles dont l’activation se fait par utilisateur. La condition d’activation peut être déterminée par un profil de permissions ou encore l’appartenance à un échantillon. Au lieu de plusieurs environnements, un seul est nécessaire pour comparer des résultats entre différents groupe d’utilisateurs et valider une approche.

AUTRES CAS – L’activation de fonctionnalités peut aussi…

  • concerner la configuration d’un système opérationnel déjà en service afin de déterminer les meilleurs paramètres (court terme) ou bien de maintenir un service stratégique au détriment d’un autre en dégradant les performances à son profit (long terme)
  • être amenée à rester sur le long terme dans le cas du besoin de customisation de fonctionnalités par utilisateur (par exemple un mode « utilisateur premium»)

Selon Martin Fowler 1 – son blog, il existe deux axes de qualification pour un feature toggle, son dynamisme (changements au déploiement / à chaud / par requête) et sa longévité (nombre de jours / mois / années). Cette classification doit orienter vers le choix d’une implémentation.

Un rapide aperçu avec FF4J

FF4J  (Feature Flipping for Java) est un framework en licence libre apache 2.

Une fois les dépendances nécessaires ajoutées (ff4j-core, junit, ff4j-web) et la configuration paramétrée, il faudra créer un service fournissant une instance de la classe FF4J.

Étape 1. Créer un feature toggle

Cela consiste à insérer une nouvelle entrée dans un feature store (le système de stockage) précisant l’identifiant du toggle, sa description, son statut d’activation, son groupe d’appartenance, les rôles d’utilisateurs ou les stratégies associés. L’offre de système de stockage des données est large : mémoire, bases relationnelles ou no-sql.

CREATE TABLE FF4J_FEATURES (
  "FEAT_UID"            VARCHAR(100),
  "ENABLE"              INTEGER NOT NULL,
  "DESCRIPTION"         VARCHAR(1000),
  "STRATEGY"            VARCHAR(1000),
  "EXPRESSION"      VARCHAR(255),
  "GROUPNAME"           VARCHAR(100),
  PRIMARY KEY("FEAT_UID")
);

ci-dessus : Table prévue pour le stockage en base relationnelle, le champ « enable » stocke 1 pour le statut « activé » 0 pour « désactivé ».

Étape 2. Utiliser le feature toggle dans le code

L’identifiant choisi à l’étape 1 permettra de vérifier l’état d’activation.

If (ff4j.check("id.du.toggle")) {
	doBehiavorA()
}  else {
	doBehiavorB()
}

ci-dessus : si le toggle est activé alors le comportement A est joué sinon le comportement B fonctionne.

Étape 3 . Déployer le code sur un environnement

Étape 4 . Contrôler l’activation via la console d’administration

ci -dessus : Une interface graphique permet de réaliser l’opération sans nécessiter de compétences techniques.

Limites

     Ce mécanisme complexifie le code : deux cas de comportements sont implémentés en même temps donc deux fois plus de code. Il est donc conseillé de réfléchir aux bons emplacements stratégiques dans le code et de limiter le nombre de recours. Dans le même ordre d’idée, le nombre total de fonctionnalités couvertes se doit de rester faible pour rester maintenable.
     Heureusement, ce risque est diminué dans la plupart des usages puisqu’ils répondent à un besoin temporaire. Néanmoins, cette situation temporaire va induire une opération supplémentaire de nettoyage du code, une fois que la fonctionnalité est activée de manière définitive.
     Il existe également quelques cas où la sécurisation avec un toggle n’est pas envisageable. J’ai notamment déjà rencontré le cas lors d’un changement structurel important au niveau du modèle en projet .
     Il existe une controverse. En effet, les outils de gestion de versions (tel que Git) apportent une aide précieuse dans la résolution de certaines problématiques (ex. CAS 3). Si la pratique très courante du Feature Branching (séparation des fonctionnalités en branches) est jugée inadaptée face au défi de l’intégration et de la livraison continues pour les uns 1 – martin fowler blog, elle reste une réponse possible lorsque bien exécutée pour d’autres 2 – james mckay blog. Ces approches peuvent aussi être utilisées côte à côte.

     Enfin, cette approche va de pair et prendra tout son sens dans un contexte où l’automatisation des tests et des déploiements est déjà en place.

Quelques implémentations

Flaggr (Android), angular-feature-flags (Angular), rollout.io (javascript), Togglz (Java), au sein du framework Spring (Java)…

 

6 clés pour mettre en place votre management par les données

By Caroline Kaercher / 29 novembre 2017 / 2 Comments

1 à 2 ans : c’est la vitesse de renouvellement des technologies informatiques actuelles. Qui permettent entre autres de produire et de traiter toutes vos data. Utiliser les technologies, c’est aussi s’assurer un avantage concurrentiel, un pouvoir d’action et d’adaptation face à l’accélération des marchés.
La vitesse de transformation de l’Entreprise se fait sous un rythme moins soutenu, entre 5 à 7 ans.
Dès lors, comment construire un pilotage de qualité, centré sur les données ?

Retrouvez 6 clés pour vous orienter dans cette démarche.

1. Rester concentré sur vos objectifs business

L’Intelligence Artificielle est-elle indispensable alors que je ne suis pas encore capable de faire une segmentation sur ma base client ?
Il faut décliner la transformation de votre métier en plusieurs étapes, pour que l’organisation ait le temps de s’adapter. Pour vous accompagner et prendre du recul, vous pouvez faire appel à des méthodologies éprouvées comme l’approche OKR (Objectives and Key Results, utilisée chez Google et Uber) ou encore l’approche Agile. La clé est de poser les jalons de votre transformation et de prendre le temps de vous projeter dans ce changement.

2. Ne pas se laisser distraire

Data mining, Data Science ou encore Machine Learning : nombreux sont les nouveaux termes liés de près ou de loin à la gestion des données. Ils rejoindront vos plans stratégiques ou vos communications en temps utile. Pour le moment, il s’agit d’évangéliser les équipes sur la transformation, de se faire comprendre et non de complexifier.
La priorité est de définir la finalité du projet de transformation et son application concrète, avant même de lier les activités de l’Entreprise à de nouvelles terminologies.

3. Penser une gestion fédérée des données

La mise en place de la directive GDPR implique une organisation centralisée. Une instance de gouvernance des données devient indispensable : elle a a pour but d’optimiser la rationalisation des données et surtout de considérer la data comme une sujet transverse (RH, Finance, Process..).
La mise en place de cette approche vous permettra en outre de faire le point sur votre organisation (le système actuel produit-il beaucoup de doublons par exemple ?)  et le partage des données.

4. Etablir une gouvernance des données

L’objectif est que la data soit diffusée et maitrisée partout.
Même si vous n’êtes pas prêt à investir massivement, il est important de mettre en place une « Roadmap Data » qui intègre dans tout projet le budget et les ressources à mobiliser pour faire avancer la Data.

5. Se concentrer sur la qualité des données avant tout

Depuis 10 ans, un problème récurrent subsiste malgré les évolutions technologiques : la qualité des données.
Même si l’ERP, le Data Marketing ou encore le Sql ont tenté d’apporter de la structure et d’optimiser la qualité, la présence de données de moins en moins structurées n’a pas joué en faveur de leur qualité.
Un bon modèle sans bonnes données, c’est un simple algorithme.
A vous de jouer…

6. S’ouvrir à l’extérieur

Le développement de l’entreprise étendue a eu pour conséquence d’ouvrir vers l’extérieur l’intégration et l’exploitation des données. La GDPR est une opportunité à saisir mais elle oblige à raisonner en « Privacy by design », c’est à dire à intégrer la protection des données dès leur conception et à anticiper leurs usages et leurs limites.
Cette évolution incite l’Entreprise à s’appuyer sur ses ressources externes et à créer un business modèle basé sur l’interopérabilité.
Il s’agit également de considérer la donnée sous l’angle éthique ou « bien commun » et de développer la transparence.




Mathias Oelher, Chief Data Officer, FDJ


En conclusion, quelques pistes de réflexion basées sur des exemples d’usage.

  • La Française des Jeux propose au téléchargement l’ensemble des grilles de résultats du loto.
    Pouvez-vous partager certaines de vos données pour renforcer votre image de transparence, voir créer de nouveaux relais de croissance ?
  • Dans ses projets liés à la lutte contre la fraude et le blanchiment, la FDJ intègre un référent Marketing et un Data Steward (administrateur des données internes) pour que tout projet puisse être co-construit dans une logique d’ouverture.
    Pourquoi ne pas intégrer un nouveau profil à vos équipes projets, comme un Change Manager pour accompagner au quotidien l’évolution de votre organisation, vérifier l’intégration du changement dans les projets, évangéliser et communiquer sur les nouveaux usages ?

Cet article a été rédigé suite à notre participation à Cloud Expo 2017 et à la conférence de Mathias Oelher Chief Data Officer à la Française des jeux.