• Ce blog — désormais archivé — est en lecture seule.

Feature branch, Feature toggle pattern

Bonsoir,

Hier c’était devops meetup, 5ème du nom, où j’ai pu voir que JMX, ce n’était pas ma vie mais que ça semble tout de même cool !

JMX c’est un outil de monitoring Java plutôt mal connu et de mauvaise réputation alors qu’au contraire, il est très intéressant (enfin, pour ceux qui font du Java). La présentation était excellente et rondement bien menée.

Ce qui m’a poussé à écrire cet article, c’est la partie sur le Feature toggle Pattern. Oui ça en jette grave mais au fond, c’est un concept que tout le monde devrait connaître. Ce patron vise à activer de nouvelles fonctionnalités d’un service en production. Il y a plusieurs manières de le faire avec des attentes différentes.

Déployer en production

  • Sauce Weka : on pousse en prod, on regarde Pinba (ou tout autre outil de monitoring) et là : il s’affole et on rollback ou tout est ok, Next !
  • Sauce plus traditionnelle : la preprod contient la nouvelle fonctionnalité et tout a été testé (le top c’est avec des données de prod répliquées à J-1, une preprod quoi…), on déploie le code versionné de preprod sur la prod, normalement pas de soucis. Au pire on rollback.
  • Sauce Facebook : on déploie par groupe, ce qui permet de tester en situation réelle sans pour autant compromettre toute l’application.
  • Sauce random : On ouvre la nouvelle fonctionnalité aléatoirement sur un délai donné avant de l’ouvrir à tout le monde.

Pour…

  • Améliorer/Faire évoluer l’existant.
  • Ajouter une nouveauté.
  • A/B testing
  • Canary testing (test du canari, provient d’une sombre histoire de mines) : soit ça marche, soit t’as perdu.
  • Tester la viabilité d’une fonctionnalité : si elle plait ou non, si elle est rentable, si elle est acceptée.

Le Feature toggle pattern est une solution qui répond principalement aux trois dernières attentes. Il s’agit de rendre possible l’activation mais surtout la désactivation d’une fonctionnalité en instantanée sans rollback lourd et contraignant (les gens qui font du Java savent ce que c’est que redéployer).

 J’en viens donc à la partie technique, comment fait-on ?

Il nous faut deux implémentations d’une même interface, un dispatcher et une variable/propriété en guise d’interrupteur. Le dispatcher va lire cette variable et renvoyer vers l’une ou l’autre des deux implémentations, ce n’est pas bien compliqué et Martin Fowler l’illustre parfaitement bien dans son article sur le Feature toggle.

Mais au fait, pourquoi un titre qui parle de Feature Branch ?

C’est plus ou moins lié. Vous connaissez surement l’article A successful Git branching model, il ne fait qu’exposer ce principe. Chaque nouvelle fonctionnalité est développée dans une branche à part et soit on merge par la suite, soit non.

On peut donc utiliser ce modèle pour développer notre feature toggle :

  • une branche master : le code stable.
  • une branche new_feature : le code de la nouvelle fonctionnalité.
  • une branche new_feature_toggle : l’intégration de la nouvelle fonctionnalité dans le code stable avec le dispatcher et l’interrupteur qui va bien.

On déploie notre branche new_feature_toggle et on valide nos objectifs. Si c’est ok, on pourra merger new_feature dans le master et tout restera propre. Je dis cela parce que, lors de la soirée, des gens ont évoqué la propreté du code et la présentation évoquait la duplication du code. Ce système de trois branches amenuise ces problèmes.

Je ne l’ai pas dit avant mais le système de feature toggle a une durée de vie limitée. Il ne s’agit pas d’avoir en permanence la possibilité d’activer ou de désactiver des fonctionnalités même si dans l’absolu, « why not ?! ».

Symfony2, encore.

En discutant avec mon pote @Fabpom, nous avons pu faire l’analogie Java/Symfony2 assez aisément. Mettre en oeuvre le principe de feature toggle avec Symfony2, ce n’est ni plus ni moins que charger un service ou l’autre lors du boot de l’application. On peut imaginer la lecture d’une valeur dans un fichier YAML et le tour est joué.

So ?

L’idée est là, le concept est en place et fait son job. Il ne faut pas hésiter à se poser la question lorsque l’on développe et que l’on nous impose un certain « sans filet ». C’est un pattern à connaître et qui peut faire gagner pas mal de temps… et d’argent ;)

  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Twitter
  • Google Bookmarks
  • FriendFeed
  • LinkedIn
  • MySpace
  • Netvibes
  • PDF
  • Ping.fm
  • RSS
  • Technorati
  • viadeo FR
  • Wikio
  • Yahoo! Buzz

Related Posts

Cet article a été publié dans ParisDevops avec les mots-clefs : , , , . Bookmarker le permalien. Les commentaires et les trackbacks sont fermés.

4 commentaires

  1. Le 20 juin 2011 à 10 h 18 min | Permalien

    hey!

    Tres interressant comme toujours!

    juste un petit troll en passant: Comment as tu « pu faire l’analogie Java/Symfony2 assez aisément » ? :D

    Sinon, concernant la duplication du code, je pense qu’ils parlaient de la duplication inhérente au dispatcher + les 2 implémentations, qui existera toujours dans la branch « new_feature_toggle », non?

    On peut pas empécher de faire temporairement vivre 2 implémentations (qui différent uniquement par la nouvelle feature) dans le meme code, d’ou l’idée de duplication je pense.

    • Le 20 juin 2011 à 20 h 15 min | Permalien

      Hello !

      Disons que le code montré était du Spring, voilà pourquoi l’analogie était vite faite ;)

      D’après ce qui était dit, c’était plus de la duplication de code « à la râche« . Mais ce que tu dis peut-être un de leurs arguments en effet :)

  2. Gaëtan
    Le 22 juin 2011 à 12 h 01 min | Permalien

    Et question, le pattern tu l’appliques comment quand il y a un impact sur la base de donnée (au niveau structure de table) ? Il n’y a pas de risques de pertes de données dans l’histoire ?

    • Le 22 juin 2011 à 12 h 17 min | Permalien

      Ce n’est clairement pas un pattern à utiliser avec impact sur une base de données, à moins que tu crées de nouvelles tables pour ne pas impacter les données existantes…
      C’est un pattern après tout, chacun l’utilise à sa manière.