[Résumé Agile2015]
It’s more than Feature Toggles: enabling Applications for Continuous Delivery

Présentateur: Daniel Piessens
Agile 2015, Mardi AM, http://sched.co/36Ps

Ceci est un résumé écrit rapidement en direct de la conférence. Soyez indulgent.

Cette présentation suppose une connaissance de ce qu’est un Feature Toggle. Si vous ne savez ce qu’est une Feature Toggle, je vous invite à d’abord lire ceci de Martin Fowler.

En gros, cela vous permet de livrer continuellement des morceaux de fonctionnalités en production (éventuellement une seule branche), mais de ne pas activer les fonctionnalités incomplètes ou dont l’annonce n’est pas faite.

C’est un rouage assez important si vous voulez vous diriger vers du déploiement/livraison continu. Même si ce n’est pas la seule approche.

À retenir (selon sa présentation)

  • Un commutateur (Feature Toggle) est de la dette technique!
  • Il faut maîtriser l’OO, l’IoC (inversion de contrôle) et le polymorphisme sur le bout de vos doigts!
  • Cela prend une intégration continue sérieuse et une seule branche (ou presque)

Résumé

Les branches

Pour faire de l’intégration continue, théoriquement, il faut avoir une seule branche: le « trunk » ou du moins avoir l’impression d’en avoir qu’une seule. On peut utiliser des « Feature Branches », mais ont doit avoir l’impression d’avoir un seul tronc (donc fusions très très fréquentes).

Vous pouvez avoir un tronc par produit ou un seul pour toute votre entreprise (ex.: Google).

Les commutateurs (Feature Toggles) sont de la dette technique!

Vous utilisez probablement des commutateurs parce que vous allez livrer en « production » du code incomplet. Donc il faut que « l’ancien code » s’exécute et pas le nouveau…

Ces branchements ont de la valeur tant que la fonctionnalité ne doit pas être activée de manière permanente. Mais une fois que l’on veut la nouvelle fonctionnalité active en production alors à quoi sert le commutateur?

À partir de ce moment, le code à exécuter lorsque le commutateur est « désactivé » devient du code mort et du bruit! Le code est compliqué pour rien et il faut maintenir du code qui ne sert plus!

Une fois que l’on a réalisé cela, cela implique qu’il faut prévoir un moment pour aller les retirer! C’était une dette nécessaire pour faciliter le processus et il faut enlever cet échafaudage dès que possible.

Normalement ce sont les « affaires » qui vous diront quand vous pourrez enlever votre commutateur (et donc le code mort qui venait avec). Cela peut-être immédiatement après la livraison activant définitivement la fonctionnalité ou encore une itération après.

Les tests

1) Le fait d’utiliser des commutateurs ou de l’intégration continue ne signifie pas forcément de ne faire aucun test manuel. Par contre, les tests automatisés constituent la base forte (dans le sens de fondation sur laquelle repose le processus). Vous n’avez qu’à mettre le commutateur actif en production après avoir fait les tests.

2) Pensez à avoir un mécanisme qui permet aux tests d’activer automatiquement les fonctionnalités nécessaires pour ce test et revenir à l’état normal (comme en production) entre les tests.

3) N’oubliez pas de tester unitairement les deux côtés du commutateur (activé et désactivé)…

Pouvoir choisir ses implémentations

Cela ne suffit pas d’avoir un moyen de « désactiver » l’expression d’une fonctionnalité. Vous pourriez, par exemple, ne pas afficher l’option dans un menu, ou avoir un accès ou encore avoir un commutateur dans le code (un IF).

Par contre, n’oubliez pas que la fonctionnalité est possiblement incomplète. Elle peut aussi dépendre de modifications aux données à faire seulement à l’activation finale. Ou encore, modifier le comportement de fonctionnalités existantes qui ne doivent pas basculer dans le nouveau « mode » avant l’activation de la nouvelle fonctionnalité…

Donc, il faut aussi pouvoir basculer entre plusieurs implémentations de « connaisseurs », « algorithmes », etc. en fonction des fonctionnalités qui sont actives ou pas.

Vous devez donc choisir des implémentations.

Exemple:
Fonctionnalité A ACTIVE → Repository Client: Implementation B → Connecteur FraudSystem: FakeFraudSystem → FraudAnalyser : IntelligentFraudAnalyser
Fonctionnalité A DÉSACTIVÉE → Repository Client: Implementation A → Connecteur FraudSystem: AcmeFraudSystem → FraudAnalyser : BlackListFraudAnalyser

Si vous gérez tout cela avec des conditions (IF) ça risque de mal finir!

Utilisez au maximum l’inversion de contrôle (IoC), le polymorphisme en général, les interfaces (abstractions) et comprenez bien le DIP (principe SOLID).

Cela va vous aider à garder cela simple, mais aussi à faire le ménage. Rappelez-vous ça va devenir de la dette!

Bref, maîtrisez votre polymorphisme, l’IoC et le DIP (principe SOLID) si vous voulez vous lancer dans l’arène!

Astuces en vrac

  • Vous pouvez utiliser des mécanismes existants d’authentification et de gestion des droits.
  • Il est fortement recommandé d’utiliser une interface pour les configurations à même le code: FeatureToggles.IsEnabled<BookRecommandationFeature> plutôt que des « Strings » **
  • Toujours prévoir une implémentation « Dummy » pour quand la fonctionnalité est fermée pour éviter les « plantages » ;)
  • Toujours commencer une nouvelle User Story avec un « Commit » du commutateur.

Divers

Il faut que les différentes étapes menant au déploiement incluent évidemment toutes les vérifications et validations concernant la qualité. Le présentateur nomme cela « Automated Quality Gates »

Recommandation de lecture: The Phoenix Project

Note: Le présentateur a aussi parlé de stratégie pour modifier la BD, pour la partie SPA (Single Page Application) en JavaScript, etc. Mais c’est un peu trop technique pour ce résumé…

* Une bonne partie de la conférence traitait de cet aspect, mais comme c’était une démonstration, il m’est difficile de la résumer ici