Petya Petrova - Fotolia
Comprendre les bases des feature flags dans une approche DevOps
Dans cet article, découvrez les feature flags, leurs capacités, leurs limites et leurs usages dans une approche DevOps.
Les feature flags sont des outils polyvalents et puissants pour les développeurs de logiciels. Cependant, ils peuvent également profiter aux équipes adeptes du manifeste DevOps.
Un feature flag permet l’exécution conditionnelle de code sur la base de simples contrôles placés dans le code lui-même. Les développeurs utilisent les feature flags (aussi appelés feature toggles, feature switches, feature bits, conditional features, etc.) pour activer ou désactiver des parties du code pendant son évolution. Cela doit faciliter le test du code nouvellement implémenté sans multiplication des versions. Dans le cadre des opérations, le personnel peut optimiser le comportement des logiciels en production, les caractéristiques et fonctionnalités clés étant contrôlées par des « feature flags ». Ces indicateurs permettent de prendre en charge différentes options logicielles.
Dans sa forme la plus simple, un feature flag n’est guère plus qu’une simple variable définie comme vraie ou fausse. Il active ou désactive une partie du code du logiciel – généralement une fonction ou une caractéristique – qui est enveloppée dans une déclaration conditionnelle « if-then », qui utilise la variable du feature flag.
Cet extrait de code générique démontre la simplicité de ce concept :
theFeatureFlag = TRUE
…
…
if theFeatureFlag = TRUE then {
execute the code here
…
…
}
En principe, les développeurs, les testeurs et les responsables des opérations IT peuvent activer ou désactiver un nouveau bout de code sans perturber les logiciels et l’infrastructure en place.
Les cas d’usage des feature flags
Les feature flags sont populaires dans les entreprises ayant adopté l’approche DevOps parce qu’ils exigent que les développeurs et les opérations travaillent ensemble pour adapter et optimiser le logiciel.
Les développeurs peuvent également utiliser les feature flags à des fins de conception, comme avec les tests A/B. Par exemple, les programmeurs veulent optimiser et améliorer un service inclus dans un produit logiciel afin d’améliorer les performances sur certains équipements. Ainsi, ils peuvent lancer la version existante ou la nouvelle suivant les performances obtenues avec différentes infrastructures matérielles.
Vous trouverez ci-dessous un exemple générique de ce type de cas d’usage :
theNewFeatureFlag = TRUE (or FALSE)
…
…
if theNewFeatureFlag = TRUE then {
…execute the NEW code here
…
…
}
else {
…execute the OLD code instead
…
…
}
Il existe des features flags statiques et dynamiques. Dans les exemples ci-dessus, ils sont essentiellement codés en dur dans le logiciel lui-même. Cette configuration est courante dans les situations où les administrateurs IT doivent tester de nouvelles fonctionnalités ou du code qui ne sera probablement pas transféré dans l’environnement de production. Dans les cas où le marqueur conditionnel doit être dynamique, les développeurs peuvent écrire un texte séparé ou des fichiers de configuration au format YAML pour contenir les paramètres du drapeau, que le logiciel ouvre et lit à son démarrage.
Dans le cas où la DSI souhaite optimiser les performances selon les équipements déployés, elle utilisera de préférence une fonctionnalité conditionnelle dynamique. Prenons l’exemple d’un logiciel qui doit effectuer des calculs complexes. Le microprocesseur doit gérer une charge importante qui sature ses instructions. Un GPU permettrait d’accélérer et d’améliorer considérablement les performances.
Un feature flag peut vérifier la présence du GPU et agir en fonction afin de réaliser les calculs plus rapidement et plus efficacement :
…run code to check for the presence of a GPU
…now automatically set the feature flag accordingly
if GPUpresent = TRUE then {
set theGPUisPresent = TRUE
}
else {
set theGPUisPresent = FALSE
}
…the software goes on to do some common, boring work
…blah
…blah
…blah
…then the software has to do its calculations
if theGPUisPresent = TRUE then {
…perform the calculations using the GPU (do it the easy way)
…
…
}
else {
…perform the calculations using the CPU (or do it the hard way)
…
…
}
Avantages du feature flagging dans une approche DevOps
Il est clair que ces fonctionnalités conditionnelles profitent aux développeurs de logiciels, mais cela est moins évident en ce qui concerne les équipes Ops ou les métiers.
Examinons cinq façons courantes dont les feature flags peuvent améliorer les opérations informatiques.
Simplifier le déploiement des applications. Le déploiement et les mises à jour des applications entraînent généralement des temps d’arrêt. Mais les fonctionnalités conditionnelles permettent à un produit logiciel d’inclure une variété de caractéristiques et de fonctions qui peuvent être délibérément activées ou désactivées – même si elles ne sont utilisées qu’à des fins de test et de validation. Idéalement, il s’agit de réduire le nombre de versions de logiciels, et d’alléger la charge que représente le déploiement de telles applications.
Faciliter la localisation des logiciels. Les différentes régions établissent et appliquent des exigences propres pour les opérations commerciales en fonction de divers facteurs. Les feature flags permettent aux administrateurs de configurer les logiciels pour un large éventail d’environnements d’exploitation, en adaptant les configurations aux besoins spécifiques des utilisateurs.
Par exemple, supposons que le pays A autorise les organisations à collecter des données personnelles identifiables comme une date de naissance, mais que le pays B l’interdit. Avec un feature flag « pays », le logiciel peut éliminer le champ de la date de naissance des écrans de saisie de données lorsque le logiciel est déployé dans le pays B.
Les fonctionnalités conditionnelles peuvent également aider à paramétrer la langue à utiliser dans les interfaces du logiciel et dans les rapports. Hormis cette différence linguistique, les opérations telles que les correctifs, le suivi des performances et les analyses de sécurité sont unifiées. Les administrateurs suivent les mêmes processus pour le logiciel, quel que soit le pays.
Valider la production. Bien que les logiciels d’entreprise soient testés de manière approfondie avant d’être mis en production, il est presque impossible pour les développeurs de logiciels et les testeurs professionnels de vérifier toutes les combinaisons possibles de matériel, d’applications et d’autres infrastructures et dépendances avec des centres de données, avant qu’un produit ne soit mis en production. Lorsqu’une mise à jour logicielle provoque des incompatibilités, l’équipe DevOps peut toujours revenir en arrière. Une fonctionnalité conditionnelle peut désactiver le nouveau code et permettre de revenir à la version précédente. En conséquence, les déploiements sont fluidifiés et les méthodes de tests changent pour inclure idéalement des expérimentations à grande échelle.
Par exemple, l’équipe crée un nouvel algorithme complexe pour remplacer un algorithme existant. Mais une fois en production, le nouvel algorithme génère des résultats inattendus ou inutilisables pour un jeu de données particulier. Les Ops peuvent modifier le fichier de configuration du logiciel pour revenir à l’algorithme précédent, et créer un ticket d’aide pour les développeurs et les data scientists afin de résoudre les problèmes.
Basculer une charge de calcul ou des optimisations. Tous les logiciels utilisent une certaine quantité de ressources de calcul, notamment le processeur, la mémoire et les entrées/sorties réseau. Les logiciels sont conçus pour utiliser des ressources avancées, telles que plusieurs CPU, des GPU afin de traiter des calculs sophistiqués et de grandes quantités de mémoire pour des calculs parallélisés ou des montées en mémoire. Toutes les cibles de déploiement ne peuvent pas fournir toutes les ressources de calcul qu’un produit logiciel pourrait utiliser – certains serveurs peuvent être plus anciens ou contenir moins de processeurs ou moins de mémoire que d’autres.
En collaboration avec les développeurs, les administrateurs informatiques peuvent utiliser des fonctionnalités conditionnelles pour détecter les ressources disponibles sur un serveur et configurer la capacité de calcul du logiciel de manière à ne pas surcharger le serveur. Idéalement, cela pourrait contribuer à maintenir de bonnes performances logicielles sur un large éventail de systèmes cibles.
Inclure des capacités premium. Les feature flags peuvent également servir à des fins plus commerciales. Ils peuvent activer ou désactiver des fonctionnalités avancées incluses dans des versions d’essai gratuites, payantes et premium d’un logiciel. Le paramètre choisi peut dépendre de la licence choisie par un client. Cela simplifie également le déploiement pour les opérations, bien que la licence du logiciel nécessite une gestion supplémentaire.
Attention, cependant, ces fonctionnalités conditionnelles se comportent comme dans un moteur de règles. Si elles ne sont pas gouvernées, elles peuvent entrer en conflit et complètement bloquer un logiciel ou un service applicatif. Aucun outil du marché ne propose une capacité de gestions avancées pour ces features flags. Une supervision extrêmement rigoureuse est de mise pour éviter des impairs en production.
