Publications

Kill Feature Branching or Die Trying

Embrace Feature Toggles for Real and Resilient Continuous Delivery

Résumé

Le feature branching est le workflow Git par défaut de beaucoup d’équipes, et je le tiens pour un anti-pattern. J’ai écrit cet article pour dire pourquoi, pour expliquer ce que les feature toggles offrent à la place, et pour montrer avec une petite application RH en .NET combien il en faut peu pour commencer.

Les dégâts, ceux qui les ont vécus les connaissent: des branches qui divergent de main pendant des semaines, des conflits de fusion qui mangent des après-midis, des bugs et des vulnérabilités découverts à la fusion plutôt qu’au commit, et une file de branches qui attendent une date de livraison. Chacun de ces effets enfreint un principe qui fait tenir la livraison continue: intégrer en continu, tester tôt, garder main toujours livrable. Une branche courte fusionnée dans la journée ne pose aucun problème; l’anti-pattern, c’est la branche qui dure, parfois même déployée en production sans jamais revenir.

Un feature toggle est un interrupteur à l’exécution. Le code entre dans main au fil de l’écriture, le travail inachevé ou risqué reste caché derrière l’interrupteur, et l’équipe gagne ce qu’une branche ne donne jamais: des déploiements canari, une exposition par permission, des expérimentations, et un retour arrière qui est un changement de configuration plutôt qu’un redéploiement. L’article distingue quatre types de toggles, release, ops, permission et expérimentation, et en construit un avec Microsoft.FeatureManagement: un filtre qui lit un en-tête HTTP, une fonctionnalité déclarée dans la configuration, un service qui demande au gestionnaire quel chemin prendre.

En échange, les toggles exigent de la discipline: les garder temporaires, les nommer de façon cohérente, tester les deux chemins, les documenter. À ce prix, le développement sur le tronc donne des boucles de retour courtes, une correction par défaut, moins de peine pour les relecteurs et des déploiements plus sûrs. Cessez de brancher les fonctionnalités; basculez-les.

Idées clés

  • Les branches de fonctionnalité qui s’éternisent cassent l’intégration continue, les tests en amont et la branche main toujours livrable; les branches courtes fusionnées vite ne sont pas le problème.
  • Un feature toggle est un interrupteur à l’exécution: le travail inachevé arrive dans main en restant caché, et le retour arrière devient un changement de configuration.
  • Quatre types de toggles, release, ops, permission et expérimentation, chacun répondant à une question différente sur qui voit quoi, et quand.
  • En .NET, un filtre de fonctionnalité, une entrée de configuration et un gestionnaire suffisent à placer un nouveau chemin derrière un en-tête HTTP.
  • Les toggles demandent de la discipline: les garder temporaires, les nommer de façon cohérente, tester les deux chemins, documenter chaque flag.

Pourquoi j’ai écrit cet article

Pour expliquer pourquoi les feature toggles sont l’alternative la plus robuste pour les équipes engagées dans la livraison continue, pour décrire ce qu’est le feature branching et pourquoi c’est une mauvaise pratique, et pour montrer avec un exemple de projet RH en .NET combien il est facile de commencer.

Dépôts associés