Feature-Schalter: Arten, Lebensdauer und Aufräumen

Worum es geht

Ein Feature-Schalter (feature toggle, feature flag) ist eine Bedingung im Code, deren Wert zur Laufzeit aus einer Konfiguration kommt, nicht aus dem Build. Der zitierte Artikel unterscheidet vier Kategorien nach Lebensdauer und Dynamik: Release-Schalter verbergen unfertige Arbeit im Hauptzweig (kurzlebig, statisch), Experiment-Schalter teilen Nutzer auf Varianten auf (Stunden bis Wochen, pro Anfrage entschieden), Ops-Schalter drosseln oder deaktivieren Funktionen unter Last (von Hand geschaltet, meist kurzlebig, einzelne als dauerhafte Notschalter), Berechtigungsschalter («Permissioning Toggles») schalten Funktionen für bestimmte Nutzergruppen frei (dauerhaft, pro Nutzer). Der Artikel empfiehlt, die Entscheidung in einem «Toggle Router» zu bündeln, statt if flag über den Code zu streuen.

Warum es wichtig ist

Schalter ermöglichen Trunk-based Development, stufenweises Ausrollen und schnelles Zurücknehmen ohne neues Deployment. Sie vervielfachen aber die Zustände, in denen das System sein kann: Bei zehn unabhängigen Schaltern sind es 1024 Kombinationen, von denen die Tests wenige abdecken. Vergessene Release-Schalter werden zu dauerhaften Verzweigungen, die niemand mehr versteht.

So wird es angewendet

• Für jeden Schalter beim Anlegen festhalten: Kategorie, Zweck, Besitzerin, Erstellungsdatum, geplantes Ausbaudatum. Release-Schalter bekommen ein Ablaufdatum kurz nach dem vollständigen Ausrollen.
• Entscheidungslogik an einer Stelle: Der Code fragt «ist Funktion X in diesem Kontext aktiv?», nicht «welcher Wert steht in der Konfiguration?». Die Antwort wird als Abhängigkeit hereingereicht, damit Tests beide Seiten erzwingen können.
• Beide Seiten eines Release-Schalters in der Pipeline testen, bis der Schalter entfernt ist: mindestens den Standardpfad und den Pfad mit allen Schaltern in Zielstellung.
• Schalterstände pro Umgebung sichtbar machen (eine Seite oder ein Endpunkt, der alle Schalter mit Wert und Herkunft auflistet) und Änderungen protokollieren.
• Ausbau als eigene Aufgabe einplanen: Bedingung entfernen, toten Zweig löschen, Tests anpassen, Konfiguration bereinigen. Überfällige Schalter erscheinen im Backlog wie andere technische Schulden.
• Ops- und Berechtigungsschalter, die bleiben sollen, bewusst als Konfiguration gestalten: dokumentiert, mit Standardwert, mit Zugriffsschutz.

Stolpersteine

Ein Schalter, der Datenformate ändert, lässt sich nicht einfach zurückschalten, sobald Daten im neuen Format geschrieben wurden; dafür braucht es Expand-und-Contract. Schalterstände, die in mehreren Systemen gepflegt werden, machen Störungen unreproduzierbar. Schalter, die über eine Namenszeichenkette abgefragt werden, liefern bei einem Tippfehler still den Standardwert. Ein Experiment-Schalter, der nach dem Experiment bleibt, hält beide Varianten am Leben.