Estimation du déploiement d'un « feature flag »
Comment estimer le déploiement d'un « feature flag » : pourcentages par étapes, « kill-switches », indicateurs de contrôle et le nettoyage que personne ne prévoit. Un « feature flag » est un petit produit, pas un simple déploiement.
L’histoire met en place le drapeau, mais oublie le nettoyage, les indicateurs de performance et le dispositif d’arrêt d’urgence.
Un « feature flag » n’est pas un mécanisme de déploiement ; c’est un petit produit à part entière. Il nécessite une valeur par défaut, une procédure de contournement, une piste d’audit, un « kill-switch » et un plan de retrait. La plupart de ces éléments font défaut dans le ticket d’origine, qui se résume généralement à « intégrez-le dans un flag ». Ce ticket constitue la porte d’accès, et non la fonctionnalité elle-même.
L’estimation doit tenir compte des phases de déploiement (1 % → 10 % → 50 % → 100 %), des indicateurs permettant de décider s’il faut accélérer ou revenir en arrière à chaque phase, ainsi que du ticket de nettoyage qui supprime le drapeau une fois que la fonctionnalité est définitive. Les équipes qui ne prévoient pas cette opération de nettoyage se retrouvent, en moins d’un an, avec une base de code truffée de marqueurs obsolètes — ce qui constitue en soi une dette opérationnelle.
Ce qui se dit dans la salle
Backend : « Envelopper l’appel dans un indicateur — quelques lignes. »
SRE : « Quel indicateur nous permet de savoir que le déploiement ne se passe pas bien ? »
PM : « Quelles cohortes verront ce drapeau activé en premier ? »
Chapeau : « Qui retire le drapeau une fois que nous avons atteint les 100 %, et à quel moment ? »
Backend : « Existe-t-il un « kill switch » distinct de l’indicateur ? »
Questions qu’il convient de se poser avant de voter
- Mode de déploiement : rampe linéaire, par cohorte ou basculement binaire ?
- Valeur par défaut lorsque le service « flag » est hors service — ancien comportement ou nouveau ?
- Les indicateurs qui déterminent le passage d’une phase à l’autre — qu’est-ce qui signifie que « tout se passe bien » ?
- Le chemin d’accès au « kill switch » est-il indépendant du système de drapeaux ?
- Bon d’enlèvement : à établir dès le départ, ou « on s’en occupera plus tard » ?
- Historique des modifications : qui a modifié le drapeau, quand et pourquoi ?
La solution est la même que pour la plupart des « stories » de déploiement : split la mise en œuvre, le déploiement par étapes et le nettoyage en « stories » distinctes, puis créez le ticket de suppression avant d’oublier qu’il existe.
Un drapeau est un petit produit. Évaluez la phase de démarrage, les indicateurs de lancement et le nettoyage — pas seulement la mise en place.
Consultez « Estimation d’un déploiement avec limitation de débit » pour découvrir le même modèle « le déploiement accapare le travail », ainsi que les autres exemples d’estimation concrets. Lancez une session gratuite de Planning Poker une fois que les phases ont été nommées.