La technique du feature flipping consiste à activer ou à désactiver des fonctionnalités au sein d’une application.

Elle est d’un intérêt non négligeable dans le cadre d’une stratégie de continous deployment, puisqu’elle va permettre :
– 1er intérêt : de déployer en acceptation voire en production des fonctionnalités non encore “releasées”, ou non encore testées, que l’on souhaite évidemment désactiver ;
– 2ème intérêt : de faire ce que l’on appelle du A/B testing, soit libérer des fonctionnalités pour certains utilisateurs en les cachant pour d’autres ;
– 3ème intérêt : d’activer sélectivement les fonctionnalités selon un planning préétabli ;
– 4ème intérêt : de dégrader partiellement les fonctionnalités d’un site en cas de situations critiques (surcharge, perte de services externes, etc.).

Quel intérêt me direz-vous?

La réponse est simple : vous devriez normalement pouvoir réduire le nombre de vos releases et donc aussi le nombre de vos déploiements.

Explication :

Dans le cadre du 1er intérêt, cela devrait vous permettre de simplifier la problématique du branching / merging, avec, on peut l’espérer, un effet bénéfique sur le nombre de déploiements.

Dans le cadre du 2ème intérêt, l’A/B testing, voici 3 exemples :

Exemple 1 :
– vous avez défini dans votre projet une itération qui comprend 3 fonctionnalités;
– les 3 fonctionnalités étant liées, vous les avez développées dans le cadre d’un même release;
– pour avoir un contrôle fin sur l’acceptation, vous souhaitez en permettre l’accès une par une;
– il serait coûteux (et de mauvais goût) de solliciter 3 fois l’équipe de déploiement
… le feature flipping est une solution.

Exemple 2 :
– vous avez défini dans votre projet une itération qui comprend 3 fonctionnalités;
– la fonctionnalité n° 1 est utilisée par le rôle A et les 2 et 3 par le rôle B;
– les 3 fonctionnalités étant liées, vous les avez développées dans le cadre d’un même release;
– pour avoir un contrôle fin sur l’acceptation, vous souhaitez en permettre l’accès rôle par rôle ;
– il serait coûteux (et de de mauvais goût) de solliciter 2 fois l’équipe de déploiement
… le feature flipping est à nouveau une solution.

Exemple 3 :
– votre projet est destiné à une utilisation par un large public, avec plusieurs groupes cibles;
– vous souhaitez procéder à une montée en charge progressive, en libérant l’accès aux groupes cibles de manière progressive;
– il serait coûteux de rédeployer à chaque fois que vous ajoutez un groupe cible
…

Les 3ème et 4ème intérêts mentionnés sont évidents : l’économie sur le nombre de déploiements est immédiate.
Le 4ème intérêt mérite une mention particulière, puisqu’en situation d’urgence le feature flipping offre des possibilités de réaction rapide.

Le framework Grails offre un exemple très abouti de feature flipping, puisqu’il permet d’activer / désactiver les fonctionnalités par serveur et par rôle, via les fichiers de configuration (en XML notamment).
www.grails.org/plugin/feature-flipper

Le feature flipping n’est certainement pas une panacée.  Mais il peut constituer une aide potentielle pour la réduction du nombre de déploiement … et donc aussi du coût des projets.

Si vous voyez des failles dans le raisonnement n’hésitez pas à réagir.