Ein Feature Flag trennt die Bereitstellung von Code von der Aktivierung einer Funktion. Diese Trennung ist nützlich, solange eine Änderung geprüft oder koordiniert wird. Bleibt ein Flag jedoch ungeprüft bestehen, kann es vergessene Codepfade hinterlassen und jede weitere Wartung erschweren. Es zu entfernen bedeutet nicht nur, eine Bedingung zu löschen: Das Team muss entscheiden, welches Verhalten bestehen bleibt, prüfen, wer davon abhängt, und sicherstellen, dass die Bereinigung andere Abläufe nicht beeinträchtigt.
Das praktische Ziel besteht darin, jedes vorübergehende Flag als Element mit einem klaren Zweck, einer verantwortlichen Person und einem festgelegten Abschlusskriterium zu behandeln. So kann das Team Flags behalten, die weiterhin eine Funktion erfüllen, und solche entfernen, die inzwischen nur noch technische Schulden darstellen.
Welche Art von Flag liegt vor, und wozu dient es?
Bevor du den Code änderst, solltest du die Funktion des Flags bestimmen. Nicht jedes Flag sollte nach demselben Zeitplan entfernt werden, und manche sind nicht als vorübergehende Lösung gedacht. Eine einfache Einteilung hilft, sowohl eine verfrühte Entfernung als auch ein unbedachtes Weiterführen zu vermeiden:
- Launch-Flag: Steuert den Zugriff auf eine Funktion, die gerade eingeführt wird. Wenn das neue Verhalten inzwischen das gewünschte Produktverhalten ist und kein Rückweg zum vorherigen Verhalten über das Flag benötigt wird, kann es meist entfernt werden.
- Experimentier-Flag: Ermöglicht den Vergleich von Varianten oder begrenzt einen Test. Nach Abschluss des Experiments und der Entscheidung, welche Variante beibehalten wird, sollte das Flag überprüft werden. Bleiben seine Bedingungen ohne aktive Hypothese bestehen, können Ergebnisse und Codepfade unklar werden.
- Dauerhafte Konfiguration: Dient dazu, ein Betriebsverhalten oder eine Produktoption fortlaufend anzupassen. Sie stellt nicht unbedingt technische Schulden auf Zeit dar und benötigt wie jede gepflegte Konfiguration Dokumentation, Kontrollen und eine verantwortliche Person.
Es kann auch Notfall- oder Betriebs-Flags geben, mit denen sich eine Funktion in bestimmten Situationen deaktivieren lässt. Entferne sie nicht allein deshalb, weil sie schon lange im System vorhanden sind. Kläre zuerst, ob ein aktueller Bedarf besteht und ob eine andere Möglichkeit denselben Zweck erfüllt. Entscheidend ist nicht, wie lange ein Flag existiert, sondern welche Entscheidung oder Fähigkeit es heute ermöglicht.
Verantwortliche und Entfernungskriterium von Anfang an festlegen
Am wirksamsten lässt sich ein vergessener Bestand vermeiden, wenn der Lebenszyklus bereits beim Anlegen des Flags dokumentiert wird. Halte mindestens den Zweck, eine eindeutig benannte verantwortliche Person, das gewünschte Verhalten, das bestehen bleiben soll, sowie einen Prüftermin oder ein auslösendes Ereignis fest. Der Termin muss nicht automatisch zur Entfernung führen; er sorgt dafür, dass die Entscheidung nicht ohne Zuständigkeit bleibt.
Formuliere das Abschlusskriterium so, dass es überprüfbar ist. Das Team kann beispielsweise vereinbaren, das Flag nach dem Ende eines Tests, dem Abschluss einer Migration oder der Bestätigung, dass das neue Verhalten übernommen wurde, zu überprüfen. Vermeide vage Angaben wie „bei Gelegenheit entfernen“. Hängt das Kriterium von einer Produktentscheidung ab, benenne, wer sie treffen soll und welche Informationen dafür erforderlich sind.
Ein minimaler Eintrag kann Folgendes enthalten:
- Name und Fundort des Flags.
- Typ und Grund für seine Einführung.
- Verantwortliche Person für die Entscheidung und die Codeänderung.
- Potentiell betroffene Nutzer, Umgebungen oder Dienste.
- Entfernungskriterium und Prüftermin.
Hat ein Flag keine verantwortliche Person, sollte der erste Schritt nicht darin bestehen, es blind zu löschen. Weise jemandem die Prüfung des Zwecks und der Abhängigkeiten zu oder gib die Entscheidung an das Team weiter, das diesen Produktbereich betreut.
Prüfen, wer vom Flag abhängt
Bevor du einen Codepfad festlegst, untersuche alle Stellen, an denen das Flag ausgewertet oder konfiguriert wird. Eine Suche im Repository kann direkte Referenzen aufdecken, zeigt aber nicht unbedingt indirekte Nutzer, außerhalb des Codes gespeicherte Regeln oder Unterschiede zwischen Umgebungen. Gleiche die Suchergebnisse deshalb mit dem Konfigurationssystem und den Abläufen des Teams ab.
Prüfe systematisch:
- Referenzen im Code: Finde Bedingungen, Hilfsfunktionen, Tests und Komponenten, die das Flag auslesen. Suche auch nach früheren Namen, falls es umbenannt wurde.
- Konfiguration je Umgebung: Prüfe, ob die Werte in Entwicklung, Test und Produktion voneinander abweichen. Gehe nicht davon aus, dass der in einer Umgebung beobachtete Zustand auch für die anderen gilt.
- Reichweite bei Nutzern: Kläre, ob die Bedingung für alle oder nur für bestimmte Segmente, Konten oder Rollen gilt. Ein Codepfad, der für eine Gruppe noch aktiv ist, kann bei allgemeinen Tests unbemerkt bleiben.
- Externe Abhängigkeiten: Prüfe Betriebsdokumentation, automatisierte Aufgaben und andere Komponenten, die den Zustand des Flags auslesen oder ändern.
- Beobachtete Nutzung: Wenn Telemetriedaten verfügbar sind, untersuche, ob und in welchem Kontext das Flag ausgewertet wird. Fehlende Ereignisse sind nur dann aussagekräftig, wenn die Instrumentierung die relevanten Abläufe abdeckt.
Telemetrie liefert Hinweise, ersetzt aber nicht die Prüfung des Designs. Ein selten genutzter Pfad, eine Umgebung ohne Datenverkehr oder unvollständige Messwerte können fälschlich den Eindruck erwecken, niemand sei vom Flag abhängig.
Alternative Codepfade kontrolliert entfernen
Sobald das endgültige Verhalten feststeht, vereinfache die Logik so, dass die Anwendung diese Entscheidung direkt abbildet. Bleibt die neue Variante bestehen, entferne den alten Zweig und die Bedingung, die keinen Nutzen mehr hat. Wird die vorherige Variante gewählt, entferne die verworfene Alternative. Ersetze ein altes Flag nicht durch ein neues, wenn es dafür keinen klaren betrieblichen Grund gibt: Das verschiebt die technischen Schulden, statt sie zu beseitigen.
Teile die Änderung in nachvollziehbare Schritte auf. Entferne zuerst Code-Referenzen und Tests, die ausschließlich für die verworfene Option vorhanden waren; anschließend kannst du die Definition und die Konfigurationswerte löschen. Betrifft das Flag mehrere Dienste oder Repositorys, stimme die Reihenfolge ab, damit eine Aktualisierung keine Komponenten zurücklässt, die auf eine nicht mehr vorhandene Option warten. Lässt sich nicht alles in einer Änderung erledigen, dokumentiere die offenen Abhängigkeiten und lege fest, wer sie jeweils abschließt.
Die Tests sollten das verbleibende Verhalten abdecken und nicht nur nachweisen, dass das Flag verschwunden ist. Führe die relevanten Tests für die geänderten Pfade aus und ergänze oder passe Fälle für die Grenzen an, die von der Bedingung abhingen: etwa Berechtigungen, Fehler, leere Zustände oder Unterschiede zwischen Umgebungen, sofern sie für das System relevant sind. Prüfe die Änderung außerdem auf überflüssige Bedingungen, unerreichbaren Code und Annahmen, die nicht mehr getestet werden.
Abschluss anhand von Signalen und Dokumentation validieren
Bevor du die Aufgabe als erledigt markierst, prüfe, ob der kompilierte oder ausgeführte Code das Flag nicht mehr abfragt und ob die zugehörige Konfiguration aus den relevanten Umgebungen entfernt wurde. Kontrolliere auch Dashboards, Warnmeldungen, Supportanweisungen und Dokumentation: Sie sollten nicht länger darauf hindeuten, dass jemand das Flag ändern kann. Verändert die Änderung einen sichtbaren Ablauf, prüfe das Ergebnis anhand der üblichen Produktkriterien und beobachte nach der Auslieferung die verfügbaren Signale.
Lege abhängig vom Risiko der Änderung im Voraus fest, was du beobachten möchtest und wie lange. Es kann genügen, Fehler, den Abschluss von Aufgaben oder Vorfälle im betreffenden Ablauf zu prüfen. Lege keinen Schwellenwert fest, wenn dem Team dafür eine Vergleichsbasis fehlt. Tritt eine Regression auf, kläre, ob sie auf die funktionale Entscheidung, eine übersehene Abhängigkeit oder den Wegfall einer betrieblichen Schutzmaßnahme zurückzuführen ist.
Wenn das Risiko eine Wiederherstellungsmöglichkeit rechtfertigt, entscheide ausdrücklich, wie sie aussehen soll. Eine dokumentierte Rückfalloption für einen begrenzten Zeitraum kann sinnvoll sein. Ein Flag dagegen unbegrenzt ohne Zuständigkeit und klare Einsatzkriterien bestehen zu lassen, ist es nicht. Halte die Entscheidung fest und setze einen neuen Prüftermin, wenn die Entfernung aufgeschoben wird.
Wann ein Flag bleiben sollte: Checkliste
Ein Flag sollte bestehen bleiben, wenn es weiterhin eine erforderliche Konfiguration, ein noch laufendes Experiment oder eine nicht anderweitig abgedeckte Reaktionsmöglichkeit steuert. Hinweise auf eine mögliche Entfernung sind dagegen eine bereits getroffene Produktentscheidung, eine nicht mehr verwendete oder benötigte Alternative und das Fehlen von Teams oder Abläufen, die auf das Flag angewiesen sind. Dass ein Flag immer aktiviert ist, ist ein Hinweis, aber kein Beweis: Prüfe zuerst, ob dieser Zustand für alle relevanten Nutzer und Umgebungen gilt.
Integriere die Bereinigung in die regelmäßigen Abläufe des Teams. Suche bei jeder Produkt- oder Wartungsprüfung nach abgelaufenen Flags, Flags ohne Verantwortliche oder Abschlusskriterium sowie Flags, die mit beendeten Experimenten verbunden sind. Priorisiere solche, die häufig genutzte Pfade verzweigen oder geplante Änderungen erschweren. Eine kurze Liste verhindert, dass die Bereinigung zu einem separaten Vorhaben wird, das immer wieder verschoben wird.
- Sind Zweck und Typ des Flags klar?
- Sind eine verantwortliche Person und ein Entfernungskriterium dokumentiert?
- Wurden Code, Konfiguration, Umgebungen und Nutzer geprüft?
- Ist entschieden, welches Verhalten bleibt, und sind verworfene Zweige entfernt?
- Decken die Tests die betroffenen Abläufe ab, und werden die Signale nach der Änderung beobachtet?
- Sind Dokumentation und Abläufe aktualisiert und ist die veraltete Konfiguration entfernt?
Eine sorgfältige Entfernung verringert die Zahl möglicher Codepfade und macht die getroffene Entscheidung im Code deutlicher. Ist eine Frage aus der Checkliste noch offen, formuliere die Unsicherheit als konkrete Aufgabe mit verantwortlicher Person und Prüftermin. So erfüllen vorübergehende Feature Flags ihren Zweck, ohne zu dauerhaft verborgenen Verzweigungen zu werden.