Release notes de feature flag : quoi dire, et quand
6 min de lecture
Fermer la boucle sur une demande de fonctionnalité suppose un moment net où la chose a été livrée. Un feature flag supprime ce moment, et c’est ce qui rend les release notes de feature flag si délicates à caler dans le temps. Le code est fusionné, le flag existe, et pendant des jours ou des semaines la fonctionnalité est à la fois en production et invisible pour presque tout le monde qui pourrait vouloir l’utiliser, y compris, souvent, la personne qui l’a demandée à l’origine. Prévenir trop tôt la fait tomber sur une fonctionnalité qui n’est pas encore là. Prévenir trop tard fait que la boucle censée construire la confiance se lit, au contraire, comme oubliée.
Pourquoi un flag casse-t-il la séquence habituelle « livrer, prévenir » ?
Parce qu’il divise un événement en au moins deux : le code qui devient actif, et le flag qui s’active pour un compte donné. Tout processus de fermeture de boucle de feedback suppose que ces deux choses arrivent ensemble, ce qui est vrai pour la plupart des livraisons et faux pour tout ce qui se trouve derrière un flag utilisé pour un déploiement progressif, du ciblage ou comme interrupteur d’urgence. Fermer la boucle de feedback client décrit le fait de prévenir la demandeuse au moment précis où une entrée de changelog est approuvée et publiée ; cette étape est écrite pour le cas où publier l’entrée et la fonctionnalité devenant utilisable sont le même moment, et un flag est exactement le cas où ils ne le sont pas.
| Moment | Ce qui est vrai | Faut-il déjà prévenir la demandeuse |
|---|---|---|
| Code fusionné, flag éteint partout | La fonctionnalité existe, personne ne peut l’utiliser | Non |
| Flag activé pour le compte de la demandeuse | La fonctionnalité existe, elle peut spécifiquement l’utiliser | Oui |
| Flag activé pour un pourcentage de déploiement qui l’exclut | La fonctionnalité existe, elle ne peut toujours pas l’utiliser | Non |
| Flag entièrement supprimé, la fonctionnalité est simplement active | La fonctionnalité existe pour tout le monde | Oui, si pas déjà prévenue |
Quelle est la règle réelle pour savoir quand prévenir quelqu’un ?
Prévenir quand le flag est activé pour son compte, pas quand le code est fusionné et pas quand le flag est créé. Cette seule règle couvre chaque ligne du tableau ci-dessus, parce qu’elle relie la notification au seul fait qui compte vraiment pour la demandeuse : peut-elle, là maintenant, aller utiliser la chose. Une notification liée à la fusion ou à la création du flag est en réalité un rapport d’avancement technique, et quelqu’un qui a demandé une fonctionnalité ne veut pas un rapport d’avancement, elle veut savoir quand aller regarder.
Est-ce que ça veut dire que la demandeuse a besoin d’un accès anticipé ou spécial ?
Pas forcément, et forcer ça crée son propre problème. Si le flag est déployé progressivement pour des raisons de charge ou de stabilité, faire passer un compte en tête de file juste pour fermer une boucle plus vite sape la raison même pour laquelle le déploiement est échelonné. Les options honnêtes sont : attendre que le compte de la demandeuse atteigne le déploiement naturellement et la prévenir alors, ou, si l’urgence le justifie, l’activer délibérément en avance, comme une vraie décision de qui possède le déploiement, pas comme un effet de bord du désir d’envoyer une notification.
Et si le flag est un interrupteur d’urgence, pas un mécanisme de déploiement ?
Alors l’hypothèse sûre s’inverse. Un flag pensé pour pouvoir désactiver rapidement une fonctionnalité, plutôt que pour échelonner sa sortie, signifie généralement que la fonctionnalité est censée être entièrement active dès sa création, et le flag existe pour la sécurité plutôt que pour le séquencement. Dans ce cas, prévenir la demandeuse au moment du déploiement est correct, comme pour toute livraison sans flag ; la présence du flag est un détail opérationnel qui ne devrait pas changer quand la boucle se ferme. La distinction qui compte, c’est à quoi sert le flag, pas s’il en existe un.
Le flag change-t-il ce que les release notes de feature flag devraient dire ?
Il change quand l’entrée est publiée, pas ce qu’elle contient. Une entrée publiée au moment précis où le flag est activé pour 100 % des comptes se lit exactement comme une entrée de changelog normale, et c’est très bien ainsi ; une lectrice qui la trouve plus tard n’a aucune raison de savoir qu’un flag a un jour été impliqué. Ce qu’elle ne devrait pas faire, c’est être publiée pendant que le flag n’est activé que pour un petit pourcentage de déploiement, parce qu’une entrée de changelog publique envoie tous ceux qui la lisent, y compris les comptes sans le flag, chercher une fonctionnalité qu’ils ne trouveront pas, ce qui est une version pire du même problème, à l’échelle du produit entier plutôt qu’à l’échelle d’une seule demandeuse. Cette règle de timing est toute la différence entre des release notes de feature flag et une entrée ordinaire : le contenu est le même, seule la date de publication bouge. Comment écrire des release notes couvre la discipline du « aucune action nécessaire » qui s’applique aussi ici : il faut dire à la lectrice si ça la concerne, pas juste que ça existe quelque part.
Les e-mails de mise à jour produit devraient-ils traiter une fonctionnalité flaggée différemment ?
Oui, surtout en la retardant plutôt qu’en la réécrivant. Le modèle d’e-mail de mise à jour produit couvre les notifications ciblées face aux digests larges ; une fonctionnalité flaggée est un cas où le timing d’une notification ciblée doit être vérifié contre l’état du flag de la destinataire elle-même avant l’envoi, ce qu’un digest large ne peut pas faire facilement du tout, ce qui est une raison de plus pour laquelle un digest est le mauvais canal pour tout ce qui est encore à mi-déploiement.
FAQ
Faut-il dire à une demandeuse que sa fonctionnalité « arrive bientôt » une fois que le flag existe mais n’est pas encore activé pour elle ? Seulement s’il y a une date réelle et proche, et même là avec parcimonie. Un « bientôt » sans date se lit, passé assez de temps, exactement comme le silence, et crée une seconde promesse qui doit elle aussi être suivie et tenue.
Qui décide quand un flag est assez avancé pour fermer la boucle ? Qui possède le déploiement, pas qui possède la notification. La propriétaire du déploiement sait si « 100 % des comptes » est imminent ou encore à des semaines ; lier l’étape de fermeture de boucle à son état, plutôt qu’à une date fixe du calendrier, garde la notification honnête.
Une fonctionnalité derrière un flag permanent (jamais entièrement supprimé) reçoit-elle un jour une entrée de changelog publique ? Oui, dès qu’elle atteint ce que signifie « disponibilité générale » pour ce produit, même si le flag lui-même reste dans le code pour toujours pour des raisons opérationnelles. L’entrée de changelog parle de la disponibilité pour la lectrice, pas du détail d’implémentation de la façon dont cette disponibilité est réalisée.
Et si le flag est supprimé et que la fonctionnalité est tuée au lieu d’être livrée ? C’est un refus, pas une notification de livraison, et ça mérite le même soin que n’importe quel autre refus. Comment refuser une demande de fonctionnalité couvre ce que ce message devrait dire ; fermer la boucle honnêtement signifie parfois la fermer avec un non.
Les release notes de feature flag ont-elles besoin d’un modèle séparé d’une entrée normale ? Aucun changement de modèle, seulement une étape de vérification avant publication : vérifier l’état du flag pour le compte qui a demandé, pas seulement que le code a été fusionné, et retenir l’entrée jusqu’à ce que cette vérification passe. Tout le reste de l’entrée, la formulation, la longueur, la discipline de la FAQ, reste identique à n’importe quelle autre release note.
Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.