Wenn Feature Flags zur technischen Schuld werden

Du lieferst seit sechs Monaten Features mit Feature Flags aus. Jede neue Funktion bekommt ihr eigenes Flag. Einige Features sind seit Wochen fertig getestet und jetzt für alle Benutzer live. Aber die Flags sind immer noch im Code. Jetzt ist deine Codebasis übersät mit bedingten Verzweigungen, an die sich niemand mehr erinnert. Ein neuer Entwickler kommt ins Team, öffnet eine Datei und sieht fünf verschiedene Flag-Prüfungen. Welche sind noch aktiv? Welche können entfernt werden? Niemand weiß es.

Das sind die versteckten Kosten von Feature Flags. Sie sind mächtige Werkzeuge für Progressive Delivery, aber sie haben ein Verfallsdatum, das Teams oft ignorieren. Derselbe Mechanismus, der sicheres Ausliefern ermöglicht, kann zur Wartungslast werden, wenn du seine Entfernung nicht planst.

Warum Flags sich anhäufen

Das Problem beginnt harmlos. Ein Team muss den Zugriff auf eine neue Funktion während des Tests kontrollieren. Sie fügen ein Flag hinzu. Die Funktion funktioniert, also rollen sie sie für mehr Benutzer aus. Dann wenden sie sich dem nächsten Projekt zu. Das Flag bleibt im Code, weil das Entfernen wie zusätzliche Arbeit ohne unmittelbaren Nutzen wirkt.

Mit der Zeit füllt sich die Codebasis mit toten Bedingungen. Konfigurationsdateien werden länger. Plattform-Dashboards zeigen Dutzende von Flags, aber die Hälfte davon ist dauerhaft aktiviert. Jeder Deployment bringt unnötige Komplexität mit sich. Wenn etwas kaputt geht, verschwenden Entwickler Zeit damit, Flag-Logik zu durchforsten, die keine Rolle mehr spielt.

Die Ursache ist einfach: Teams konzentrieren sich darauf, Flags zu erstellen und zu aktivieren, vergessen aber, dass jedes Flag einen Lebenszyklus hat. Ein Flag wird geboren, erfüllt seinen Zweck und muss dann sterben. Ohne einen Plan für diesen letzten Schritt werden Flags zu technischer Schuld, die sich mit jedem Release vergrößert.

Der Lebenszyklus eines Feature Flags

Ein gesundes Feature Flag durchläuft klare Phasen. Es beginnt, wenn das Team beschließt, es zu erstellen. In diesem Moment sollte jemand den Zweck des Flags aufzeichnen: welche Funktion es steuert, wer es umschalten kann und wann es entfernt werden soll. Diese Metadaten mögen wie Overhead erscheinen, aber sie werden Wochen später unverzichtbar, wenn das Team entscheiden muss, welche Flags bereinigt werden sollen.

Nach der Erstellung durchläuft das Flag die Rollout-Phasen. Zuerst aktiviert es die Funktion für interne Tests. Dann für einen kleinen Prozentsatz der Benutzer. Dann für alle. In der letzten Phase ist die Funktion nicht mehr experimentell. Sie ist Teil der Anwendung. Das Flag hat keinen Grund mehr zu existieren.

Hier lassen die meisten Teams den Ball fallen. Sie erreichen die Phase "Alle Benutzer" und hören auf, über das Flag nachzudenken. Die Funktion funktioniert. Das Team zieht weiter. Das Flag bleibt im Code und fügt stillschweigend Komplexität hinzu.

Das folgende Diagramm fasst die vier Schlüsselphasen und die Aktionen zusammen, die ein Flag von einer Phase zur nächsten bewegen.

Zwei Praktiken, die Flag-Fäulnis verhindern

Um die Anhäufung von Flags zu verhindern, sind zwei Dinge erforderlich: ein geplanter Bereinigungsprozess und eine Möglichkeit, veraltete Flags zu erkennen.

Plane die Bereinigung in deinen Entwicklungszyklus ein

Mache die Flag-Entfernung zu einem regelmäßigen Bestandteil deines Workflows. Überprüfe am Ende jedes Sprints die Liste der Flags, die seit mehr als zwei Wochen für alle Benutzer aktiv sind. Entferne diese Flags aus dem Code und aus deiner Flag-Management-Plattform. Wenn ein Flag nicht entfernt werden kann, weil es noch für A/B-Tests oder eine unvollständige Funktion benötigt wird, aktualisiere seine Metadaten mit einem neuen voraussichtlichen Entfernungsdatum.

Das klingt einfach, erfordert aber Disziplin. Teams, die diesen Schritt für einen Sprint auslassen, überspringen ihn oft auch für den nächsten. Bald ist der Bereinigungsrückstand größer, als irgendjemand bewältigen möchte.

Erkenne veraltete Flags automatisch

Manuelle Überprüfungen reichen nicht aus. Du brauchst eine automatisierte Erkennung. Viele Feature-Flag-Plattformen können Einträge markieren, die innerhalb eines bestimmten Zeitraums nicht geändert oder überprüft wurden. Wenn deine Plattform dies nicht unterstützt, schreibe ein einfaches Skript, das die Flag-Konfiguration liest und mit dem Zeitstempel der letzten Änderung vergleicht. Flags, die seit Wochen nicht mehr angefasst wurden und für alle Benutzer aktiviert sind, sind ideale Kandidaten für die Entfernung.

Einige Teams gehen noch weiter und fügen ihrer CI-Pipeline einen Linting-Schritt hinzu. Der Linter prüft auf Flags, die länger als einen konfigurierten Schwellenwert in der Codebasis vorhanden sind, und warnt den Entwickler. Dies fängt veraltete Flags ab, bevor sie zu dauerhaften Einrichtungen werden.

Das folgende Skript sucht beispielsweise nach einem Flag-Namen im Quellcode und fragt die Flag-Management-API ab, um zu sehen, ob es dauerhaft für alle Benutzer aktiviert ist:

#!/bin/bash
FLAG_NAME="MY_FLAG"
# Zähle Vorkommen im Quellcode
OCCURRENCES=$(grep -r "$FLAG_NAME" src/ --include='*.js' | wc -l)
# Frage die Flag-Management-API nach dem Status
STATUS=$(curl -s "https://flags.example.com/api/flags/$FLAG_NAME" | jq -r '.status')
# Wenn das Flag dauerhaft aktiviert und selten referenziert ist, markiere es
if [ "$STATUS" = "permanently_enabled" ] && [ "$OCCURRENCES" -gt 0 ]; then
  echo "WARNUNG: Flag $FLAG_NAME ist dauerhaft aktiviert, wird aber noch an $OCCURRENCES Stellen verwendet."
  echo "Erwäge, es aus Code und Konfiguration zu entfernen."
fi

Warum Bereinigung über Code-Hygiene hinausgeht

Die Bereinigung von Feature Flags dient nicht nur dazu, die Codebasis ordentlich zu halten. Es geht darum, das Vertrauen des Teams in das System zu bewahren. Wenn Entwickler unsicher sind, ob ein Flag noch verwendet wird, haben sie Angst, es zu entfernen. Sie befürchten, dass eine unbekannte Abhängigkeit kaputt gehen könnte. Also bleibt das Flag, und die Konfiguration wird komplexer. Je länger es bleibt, desto schwieriger wird es zu entfernen, weil niemand alle Stellen nachvollziehen kann, an denen es eine Rolle spielen könnte.

Dieser Vertrauensverlust hat reale Konsequenzen. Neue Funktionen brauchen länger für die Implementierung, weil Entwickler um alte Flag-Logik herumarbeiten müssen. Das Debuggen wird langsamer, weil jede bedingte Verzweigung ausgewertet werden muss. Das Onboarding neuer Teammitglieder wird schwieriger, weil sie die Geschichte jedes Flags lernen müssen, bevor sie einen Beitrag leisten können.

Ein sauberer Flag-Lebenszyklus stellt dieses Vertrauen wieder her. Wenn jedes Flag einen bekannten Zweck und ein geplantes Entfernungsdatum hat, können Entwickler darauf vertrauen, dass der Code, den sie sehen, der Code ist, der zählt. Sie können Flags ohne Angst löschen. Sie können sich darauf konzentrieren, neue Funktionen zu bauen, anstatt alte Experimente zu entschlüsseln.

Praktische Checkliste für das Flag-Lebenszyklus-Management

• Zeichne den Zweck, den Besitzer und das voraussichtliche Entfernungsdatum auf, wenn du ein neues Flag erstellst.
• Überprüfe alle Flags am Ende jedes Sprints. Entferne diejenigen, die seit mehr als zwei Wochen für alle Benutzer aktiv sind.
• Verwende automatisierte Werkzeuge, um Flags zu erkennen, die kürzlich nicht geändert oder überprüft wurden.
• Füge einen CI-Linting-Schritt hinzu, der vor Flags warnt, die älter als ein konfigurierbarer Schwellenwert sind.
• Aktualisiere die Flag-Metadaten, wenn sich ein Entfernungsdatum ändert. Lasse Daten nicht ohne Bestätigung veralten.
• Entferne Flags sowohl aus dem Code als auch aus der Konfiguration. Ein Flag, das in der Konfiguration verbleibt, ist immer noch eine Haftung.

Das Fazit

Feature Flags sind nicht dauerhaft. Behandle sie wie temporäre Gerüste: Stelle sie auf, wenn du sie brauchst, und baue sie ab, wenn die Struktur von selbst steht. Ein Flag, das nach der vollständigen Veröffentlichung seiner Funktion im Code bleibt, ist kein Sicherheitsnetz. Es ist totes Gewicht. Plane die Entfernung von Tag eins an, und deine Progressive-Delivery-Pipeline bleibt schlank, schnell und vertrauenswürdig.