Feature-Flag-Release-Notes: was man sagt, und wann
5 Min. Lesezeit
Die Schleife bei einer Feature-Anfrage zu schließen setzt einen klaren Moment voraus, in dem die Sache ausgeliefert wurde. Ein Feature-Flag entfernt diesen Moment, und genau deshalb ist das Timing von Feature-Flag-Release-Notes so schwierig. Der Code wird gemergt, das Flag existiert, und für Tage oder Wochen danach ist das Feature gleichzeitig live in Produktion und für fast jeden unsichtbar, der es haben möchte, oft eingeschlossen die Person, die ursprünglich danach gefragt hat. Informiert man sie zu früh, trifft sie auf ein Feature, das noch nicht da ist. Informiert man zu spät, liest sich die Schleife, die eigentlich Vertrauen aufbauen sollte, stattdessen als vergessen.
Warum bricht ein Flag die übliche Abfolge “ausliefern, informieren”?
Weil es ein Ereignis in mindestens zwei aufspaltet: den Code, der live geht, und das Flag, das für ein bestimmtes Konto eingeschaltet wird. Jeder Prozess zum Schließen einer Feedback-Schleife setzt voraus, dass diese beiden zusammen passieren, was für die meisten Releases stimmt und für alles falsch ist, was hinter einem Flag für stufenweisen Rollout, Targeting oder als Notausschalter steckt. Die Feedback-Schleife zum Kunden schließen beschreibt, die anfragende Person genau in dem Moment zu informieren, in dem ein Changelog-Eintrag genehmigt und veröffentlicht wird; dieser Schritt ist für den Fall geschrieben, in dem das Veröffentlichen des Eintrags und die Nutzbarkeit des Features derselbe Moment sind, und ein Flag ist genau der Fall, in dem sie es nicht sind.
| Moment | Was stimmt | Sollte die anfragende Person schon informiert werden |
|---|---|---|
| Code gemergt, Flag überall aus | Feature existiert, niemand kann es nutzen | Nein |
| Flag an für das Konto der anfragenden Person | Feature existiert, sie speziell kann es nutzen | Ja |
| Flag an für einen Rollout-Prozentsatz, der sie ausschließt | Feature existiert, sie kann es trotzdem nicht nutzen | Nein |
| Flag vollständig entfernt, Feature ist einfach an | Feature existiert für alle | Ja, falls noch nicht informiert |
Was ist die eigentliche Regel dafür, wann man jemanden informiert?
Informiere, wenn das Flag für ihr Konto an ist, nicht wenn der Code gemergt wird und nicht wenn das Flag erstellt wird. Diese eine Regel deckt jede Zeile der Tabelle oben ab, weil sie die Benachrichtigung an die eine Tatsache knüpft, die der anfragenden Person tatsächlich wichtig ist: kann sie gerade jetzt losgehen und die Sache benutzen. Eine Benachrichtigung, die an den Merge oder die Erstellung des Flags geknüpft ist, ist eigentlich ein Fortschrittsbericht über die Entwicklung, und eine Person, die ein Feature angefragt hat, will keinen Fortschrittsbericht, sondern wissen, wann sie nachsehen soll.
Bedeutet das, dass die anfragende Person früheren oder besonderen Zugang braucht?
Nicht unbedingt, und es zu erzwingen schafft ein eigenes Problem. Wenn das Flag aus Last- oder Stabilitätsgründen schrittweise ausgerollt wird, untergräbt es den Grund für den gestuften Rollout, ein Konto nur deshalb an die Spitze der Warteschlange zu schieben, um eine Schleife schneller zu schließen. Die ehrlichen Optionen sind: warten, bis das Konto der anfragenden Person den Rollout auf natürlichem Weg erreicht, und sie dann informieren, oder, falls die Dringlichkeit es rechtfertigt, sie bewusst früh einzuschalten, als echte Entscheidung von wem auch immer den Rollout verantwortet, nicht als Nebeneffekt des Wunsches, eine Benachrichtigung zu verschicken.
Was, wenn das Flag ein Notausschalter ist, kein Rollout-Mechanismus?
Dann kehrt sich die sichere Annahme um. Ein Flag, das dazu da ist, ein Feature schnell abschalten zu können statt seine Auslieferung zu staffeln, bedeutet meist, dass das Feature vollständig live sein soll, sobald es erstellt wird, und das Flag existiert aus Sicherheitsgründen statt zur Sequenzierung. In diesem Fall ist es korrekt, die anfragende Person zum Deploy-Zeitpunkt zu informieren, genau wie bei jedem ungeflaggten Release; die Existenz des Flags ist ein operatives Detail, das nicht ändern sollte, wann die Schleife schließt. Die entscheidende Unterscheidung ist, wofür das Flag da ist, nicht ob eines existiert.
Ändert das Flag, was Feature-Flag-Release-Notes sagen sollten?
Es ändert, wann der Eintrag veröffentlicht wird, nicht was er enthält. Ein Eintrag, der genau in dem Moment veröffentlicht wird, in dem das Flag für 100 % der Konten an ist, liest sich genau wie ein normaler Changelog-Eintrag, und das ist richtig; eine Leserin, die ihn später findet, hat keinen Grund zu wissen, dass je ein Flag im Spiel war. Was er nicht tun sollte, ist veröffentlicht zu werden, während das Flag nur für einen kleinen Rollout-Prozentsatz an ist, weil ein öffentlicher Changelog-Eintrag jeden, der ihn liest, einschließlich Konten ohne das Flag, dazu bringt, nach einem Feature zu suchen, das sie nicht finden können, was dieselbe Art von Problem verschlimmert, nur auf Produktgröße statt auf der Größe einer einzelnen anfragenden Person. Diese Timing-Regel ist der ganze Unterschied zwischen Feature-Flag-Release-Notes und einem gewöhnlichen Eintrag: Der Inhalt ist derselbe, nur das Veröffentlichungsdatum verschiebt sich. Wie man Release Notes schreibt behandelt die “keine Aktion nötig”-Disziplin, die auch hier gilt: Leser müssen erfahren, dass es sie betrifft, nicht nur, dass es existiert.
Sollten Produkt-Update-E-Mails ein geflaggtes Feature anders behandeln?
Ja, hauptsächlich durch Verzögern statt Umformulieren. Die Produkt-Update-E-Mail-Vorlage behandelt gezielte Benachrichtigungen gegenüber breiten Digests; ein geflaggtes Feature ist ein Fall, in dem das Timing einer gezielten Benachrichtigung gegen den eigenen Flag-Status der Empfängerin geprüft werden muss, bevor sie verschickt wird, etwas, das ein breiter Digest kaum leisten kann, was ein weiterer Grund ist, warum ein Digest der falsche Kanal für alles ist, was noch mitten im Rollout steckt.
FAQ
Sollte man einer anfragenden Person sagen, ihr Feature komme “bald”, sobald das Flag existiert, aber für sie nicht an ist? Nur, wenn ein echtes, naher Termin dranhängt, und selbst dann sparsam. Ein “bald” ohne Datum liest sich nach genug Zeit genauso wie Schweigen, und es schafft ein zweites Versprechen, das ebenfalls verfolgt und eingehalten werden muss.
Wer entscheidet, wann ein Flag weit genug ist, um die Schleife zu schließen? Wer auch immer den Rollout verantwortet, nicht wer die Benachrichtigung verantwortet. Die Rollout-Verantwortliche weiß, ob “100 % der Konten” unmittelbar bevorsteht oder noch Wochen entfernt ist; den Schließ-Schritt an ihren Status statt an ein festes Kalenderdatum zu knüpfen, hält die Benachrichtigung ehrlich.
Bekommt ein Feature hinter einem dauerhaften Flag (nie vollständig entfernt) je einen öffentlichen Changelog-Eintrag? Ja, sobald es erreicht, was für dieses Produkt “allgemein verfügbar” bedeutet, selbst wenn das Flag selbst aus operativen Gründen für immer im Code bleibt. Der Changelog-Eintrag handelt von der Verfügbarkeit für die Leserin, nicht vom Implementierungsdetail, wie diese Verfügbarkeit umgesetzt ist.
Was, wenn das Flag entfernt wird und das Feature gekippt statt ausgeliefert wird? Das ist eine Ablehnung, keine Ausliefer-Benachrichtigung, und sie verdient dieselbe Sorgfalt wie jede andere Ablehnung. Wie man einen Feature-Request ablehnt behandelt, was diese Nachricht sagen sollte; die Schleife ehrlich zu schließen bedeutet manchmal, sie mit einem Nein zu schließen.
Brauchen Feature-Flag-Release-Notes eine eigene Vorlage gegenüber einem normalen Eintrag? Keine Vorlagenänderung, nur ein Gating-Schritt vor der Veröffentlichung: den Flag-Status für das Konto prüfen, das gefragt hat, nicht nur, dass der Code gemergt wurde, und den Eintrag zurückhalten, bis diese Prüfung besteht. Alles andere am Eintrag, die Formulierung, die Länge, die FAQ-Disziplin, bleibt dasselbe wie bei jeder anderen Release Note.
Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft. Wenn etwas nicht stimmt, sagen Sie es uns, und wir korrigieren es.