image

Librairie FeatureFlags : Choix de conception

Je vous ai parlé il y a peu de l’utilisation des Feature Flags qui est une technique qui facilite la mise en place d’intégration continue, je vous avais alors indiqué que les différentes implémentations disponibles en .net ne me satisfaisait pas.

imageJ’ai donc débuté le développement d’une librairie appelée tout simplement FeatureFlags.

Avant de mettre le code à disposition sur codeplex, je vais donc partager vous les différents choix de design que j’ai effectué.

J’ai opté pour un principe simple afin de faciliter la maintenance des features : je souhaite que l’utilisation du principe soit le plus fortement typé possible afin que l’on puisse agir directement sur les différents emplacements dans le code où une feature est utilisée.

Ainsi toute suppression de feature (car plus utile, par exemple dans le cas d’une activation définitive), doit lever différentes erreurs de compilation afin de forcer le développeur à supprimer tout le code inhérent.

Niveau UI

Mon besoin étant uniquement orienté autour d’applications WPF, je me suis attardé uniquement sur ce type d’intégration.

L’objectif est de pouvoir afficher ou non n’importe quel contrôle WPF en fonction de l’état d’activation d’une fonctionnalité.

Pour une intégration simple et souple, j’ai opté pour l’implémentation d’une custom MarkupExtension.

Cette solution de lier très simplement une propriété Visibility à une Feature et permet également de rester fortement typé. Si la classe de définiton de la feature est supprimée, nous nous retrouverons avec une erreur de compilation XAML facilement détectable.

image

A noter la possibilité d’afficher des contrôles en fonction de la non activation d’une feature via la définition de la propriété IsEnabled (définie à True par défaut) :

image

D’un point de vue du rafraichissement, j’ai opté pour une récupération de l’état d’activation de la feature en “One Time” uniquement au moment de la récupération de la MarkupExtension. Cela signifie que si l’état d’activation change alors que la fenêtre parent est déjà chargé, l’UI ne sera pas impactée.

Niveau Code

D’un point de vue code, le flip se fait de manière très simple :

image

Je viendrais dans un prochain post sur la gestion de la persistence de l’état des features en base de données.

N’hésitez pas à me faire part de vos remarques sur ce design par rapport aux autres libraires du marché.

5 réflexions au sujet de « Librairie FeatureFlags : Choix de conception »

  1. Laurent Kempé

    Bien joué Patrice!

    J’espère que tu as bien abstrait l’accès à la base de données qu’on puisse facilement remplacer par autre chose

    Répondre
  2. Christophe Heral

    Bonjour Patrice,

    Une telle librairie serait très intéressante.

    Je suppose qu’elle sera utilisable avec d’autres types d’IHM (MVC par exemple).

    La seule que je connaisse en .NET est FlipIt (https://github.com/timscott/flipit ) si tu souhaites comparer avec leur design.

    Petites questions :
    – Si j’ai bien compris, tu génères (via T4 ?) une classe pour chaque feature à partir de sa déclaration en BDD. C’est ça ?
    – Features semble être une classe statique. tu prévois un autre type d’appel qui permettra de faire de l’IoC avec ?

    Répondre
    1. Patrice Lamarche

      Côté UI la librairie est uniquement utilisable avec WPF pour le moment.
      Pour les features, pas de génération de code au programme, il faut créer une classe qui hérite de la classe de base Feature.
      Concernant la classe statique Features, je n’ai pas prévu une autre utilisation par exemple pour de l’IOC mais je suis preneur de toute suggestion !
      Le projet est en train d’être publié sur codeplex, n’hésites pas à me donner tes feedbacks !

      Répondre

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *