La mise en oeuvre du Continuous Delivery se heurte souvent à des arguments émis par les développeurs ou le métier. L’un des plus courants concerne la mise en production de fonctionnalités en cours de développement (c’est-à-dire des fonctionnalités dont le développement n’est pas terminé).

Un pattern de développement permet de répondre à cette problématique : le feature toogle pattern.
L’idée de base est de permettre l’activation ou non des différentes fonctionnalités via un système de configuration. L’application en production (ou en recette) n’affichant ensuite que les fonctionnalités actives.
Cette technique permet de répondre aux cas d’utilisations suivants :

  • Mettre en recette ou en production une application alors qu’une des fonctionnalités n’est pas satisfaisante  (Problème de performance, de fiabilité, etc.);
  • Permettre au métier de choisir le bon moment pour activer ou désactiver une fonctionnalité ;
  • Mettre en production (ou en recette) une application dont le développement de certaines fonctionnalités n’est pas terminé ;
  • Désactiver des fonctionnalités non cruciales lors de montée de charge en production afin de laisser les ressources machines aux fonctionnalités cruciales;
  • Permettre la mise en oeuvre du Continuous Delivery.

Par ailleurs cette technique possède de nombreux avantages :

  • Décorrèle les développements d’une fonctionnalité, de sa mise en production ;
  • Décorrèle le déploiement d’une fonctionnalité, de sa mise à disposition aux utilisateurs ;
  • Désactiver une fonctionnalité ne nécessite plus de retour arrière ou de déploiement ;
  • Activer une fonctionnalité ne nécessite plus nécessairement de déploiement ;
  • Cette technique permet de travailler sur une seule branche et elle réduit donc la charge associée au merge.

Cette technique ne comporte que peu d’inconvénients :

  • Peu utilisable lorsque le nombre de fonctionnalités désactivables est important ;
  • Augmente la charge de test, il est nécessaire de tester la fonction en mode activée ET en mode désactivée ;
  • Complexifie le code.

Et concrètement :

Un fichier de configuration contiendra l’ensemble des fonctionnalités potentiellement activables ou désactivables.

fonction.properties

supprimerClient = true
transfererClient = true
creerClient = false

Il devient même envisageable de créer une IHM à destination du métier permettant d’activer ou de désactiver les fonctionnalités (où seules les fonctionnalités complètement développées pourront être activées bien sûr).

Les pages jsp utiliseront un tag spécifique, permettant de masquer les fonctionnalités désactivées aux utilisateurs.

client.jsp

<neoxia:toggle name=”transfererClient”>
	<h2>Transférer un client<h2>
	...
</neoxia:toggle>
<neoxia:toggle name=”creerClient”>
	<h2>Créer un client</h2>
	...
</neoxia:toggle>

Dans le code, un simple test permettra d’activer ou de désactiver les fonctionnalités.

Client.java

if (toggle.isActivate(“creerClient”) then {
 Client nouveauClient = new Client();
 ...
}

L’essentiel des fonctionnalités étant à terme activées, il sera nécessaire de refactorer régulièrement le code afin de le débarrasser de ces tests devenu inutiles.
Cette technique tout simple permet une plus grande souplesse dans les déploiements… elle permet aussi de tester en grandeur nature des fonctionnalités sur un ensemble réduit d’utilisateur (Canary Releasing).

Références

Pour aller plus loin