Feature Flags richtig einführen: der Schalter, der die Auslieferung von der Freigabe trennt
Ein Feature Flag trennt zwei Dinge, die traditionell zusammenfallen: wann Code ausgeliefert wird und wann er wirkt. Diese Trennung ist der Grund, warum große Organisationen mehrmals täglich ausliefern können, ohne dass jede Auslieferung ein Ereignis ist.
Feature Flags trennen den Zeitpunkt der Auslieferung vom Zeitpunkt der Wirkung. Dadurch wird das riskante Einschalten vom aufwendigen Ausliefern getrennt, der Rückweg dauert Sekunden statt einer erneuten Auslieferung. Eine Änderung hinter einem Schalter mit kleinem Rollout und automatischer Rücknahme trägt weniger Risiko und darf niedriger eingestuft werden. Drei Fehler machen daraus eine Altlast: Schalter ohne Ablaufdatum und Verantwortlichen, Schalter als dauerhafte Kundenkonfiguration, und verschachtelte Schalter, deren Zustandskombinationen niemand testet.
Was die Trennung praktisch ändert
Code kann fertig, geprüft und ausgeliefert sein, ohne aktiv zu sein. Damit wird die riskante Handlung — das Einschalten — von der aufwendigen Handlung — dem Ausliefern — getrennt. Man kann für eine einzelne Kundengruppe einschalten, bei Problemen in Sekunden zurücknehmen, und das ohne erneuten Auslieferungsvorgang. Der Rückweg ist damit kürzer als jede Rücksetzung.
Der Zusammenhang mit der Prüftiefe
Eine Änderung hinter einem Schalter, die für ein Prozent der Nutzer aktiv ist und automatisch zurückgenommen wird, trägt anderes Risiko als dieselbe Änderung, die sofort für alle gilt. Das ist ein legitimes Kriterium für die Risikoklasse — und einer der wenigen Hebel, mit denen man die nötige menschliche Prüfung ehrlich reduziert, statt sie nur wegzulassen.
Fehler 1: Schalter ohne Ablaufdatum
Der häufigste. Ein Schalter wird eingebaut, die Funktion geht live, und der Schalter bleibt — mitsamt dem toten Zweig dahinter. Nach zwei Jahren hat die Codebasis hunderte, deren Zustand niemand kennt, und jede Verzweigung verdoppelt die Zahl der möglichen Zustände. Jeder Schalter braucht bei Anlage ein Ablaufdatum und einen Verantwortlichen, und beides gehört automatisch überwacht.
Fehler 2: Schalter als dauerhafte Konfiguration
Ein Schalter ist ein Werkzeug für eine Übergangszeit. Wird er zur dauerhaften Einstellung — Kunde A bekommt dies, Kunde B jenes — entsteht Produktvarianz im Code, die niemand mehr überblickt. Dauerhafte Unterschiede gehören in eine Konfiguration mit eigenem Modell, nicht in einen Schalter.
Fehler 3: Verschachtelung
Zwei ineinandergreifende Schalter ergeben vier Zustände, drei ergeben acht — und getestet wird üblicherweise einer. Die Regel dagegen ist unbequem und wirksam: keine Schachtelung. Wo sie unvermeidlich scheint, ist meistens der Schnitt der Funktion falsch.
Häufige Fragen
Wie viele Feature Flags sind zu viele?
Entscheidend ist nicht die Zahl, sondern das Alter. Ein Bestand mit fünfzig Schaltern, die alle jünger als drei Monate sind, ist gesund; zehn Schalter, die seit zwei Jahren liegen, sind eine Altlast. Überwachen Sie das Alter, nicht die Menge.
Braucht man dafür ein eigenes Produkt?
Für den Anfang nicht. Eine Konfiguration mit zentraler Verwaltung und sofortiger Wirkung reicht. Ein eigenes Produkt lohnt sich, wenn Zielgruppensteuerung, gestufte Ausrollung und Auswertung dazukommen — also ab dem Punkt, an dem Schalter Teil des Auslieferungsmodells sind.
Wie testet man Code hinter Schaltern?
Beide Zustände der aktiven Schalter, nicht alle Kombinationen. Deshalb die Regel gegen Schachtelung: Sie hält die Zahl der zu testenden Zustände linear statt exponentiell. Für ältere Schalter, deren Zweig nie aktiv ist, gilt: entfernen statt testen.
Wer entfernt einen Schalter wieder?
Die Person, die ihn angelegt hat, mit dem Datum aus der Anlage. Ohne benannten Verantwortlichen und Frist wird kein Schalter entfernt — das ist keine Frage der Disziplin, sondern der fehlenden Zuständigkeit.
Bringen Sie einen Pull Request mit, der zu groß war.
30 Minuten, kein Vertrieb. Wir gehen ihn durch und sagen, was ein Modell daran geändert hätte.
AI Engineering Review ansehen →
