5. Ship Small & Feature Toggles

Photo by Andrew Neel on Unsplash

Mike Coutermarsh partage dans un article (opens new window) comment l'équipe de GitHub Actions livre rapidement des fonctionnalités tout en intégrant un maximum de retour en suivant une philosophie ship small.

Dans cet article, il explique comment son équipe s'appuye sur des feature flags (opens new window) (ou feature toggles) pour déployer en production du code qui n'est pas terminé. Une fonctionnalité à ajouter est d'abord découpée en petites tâches, chacune donnant lieu à une pull request qui sera mergée et livrée en production; mais uniquement accessible via un feature flag. Cela permet de partager son code au sein de l'équipe dans un contexte commun défini par ce feature flag. Dès que la fonctionnalité est suffisamment mature, le feature flag correspondant est étendu au delà de l'équipe en charge afin d'obtenir des retours d'autres équipes. Ces retours donneront eux-mếmes lieu à de nouvelles tâches, permettant un développement incrémental de la fonctionnalité. Etre capable de livrer rapidement en production du code partiellement fonctionnel assure que celui-ci est compatible avec l'existant, notamment au travers des outils d'integration continue, augmentant ainsi la confiance de l'équipe dans ce code.

Martin Fowler (opens new window) parle de release toggles pour ces feature toggles qui cachent des fonctionnalités partiellement implémentées. Pour lui, ce type de flag ne devrait être utilisé qu'en dernier recours. Il préconise de commencer par diviser une fonctionnalité en petites unités qui peuvent être intégrées directement au produit ou, à défaut, de développer la partie visible de la fonctionnalité, l'UI, en dernier. Les release toggles restent cependant une technique courante dans le cadre d'un trunk based development (opens new window), notamment dans un contexte de livraison continue. Ils viennent alors en complément des feature branch (opens new window).

L'usage des feature toggles va cependant au delà des release toggles. Pete Hodgson (opens new window) caractérise 4 sortes de feature toggles suivant leur usage:

• les release toggles masquent des fonctionnalités en cours d'implémentation,
• les operational toggles activent ou désactivent des fonctionnalités pour des besoins opérationels - de performance, par exemple,
• les experiment toggles activent des fonctionnalités pour un sous ensemble d'utilisateur sélectionné au hasard (A/B testing),
• les permissioning toggles activent des fonctionnalités pour un ensemble spécifique d'utilisateur (premium, alpha ou beta testeurs).

Dans son article, Pete Hodgson caractérise chacune de ces catégories en fonction de leur longévité et de leur nature dynamique; deux paramètres qui vont jouer sur les choix d'implémentation sous-jacents. Par exemple, les release toggles ont une durée de vie courte et ne sont pas dynamiques, ce qui permet de les gérer par des fichiers de configuration - comme dans cette exemple avec Sprint Boot (opens new window). L'inconvénient de cette solution est qu'elle ne permet de gérer qu'une catégorie de toggle. Pour des besoins plus évolués, il est possible de centraliser la gestion de l'ensemble des toggles, quelque soit leur catégorie, dans un système de management dédié comme rollout.io (opens new window) ou l'une de ses alternatives (opens new window).