Wenn Deployment nicht gleich Feature-Release bedeutet

Ihr Team hat gerade eine große Refaktorisierung des Suchalgorithmus abgeschlossen. Der Code ist getestet, reviewed und in Produktion deployed. Aber hier ist der Haken: Niemand nutzt ihn bisher. Der neue Algorithmus liegt auf dem Server, kompiliert und bereit, aber jeder User bekommt weiterhin Ergebnisse vom alten. Das ist Absicht.

Dieses Szenario mag seltsam klingen, wenn man Deployments gewohnt ist, bei denen jede Änderung sofort die User betrifft. Tatsächlich ist es aber ein mächtiges Muster, das zwei Dinge trennt, die die meisten Teams als identisch behandeln: Code deployen und Features releasen.

Das Problem, das Deployment allein nicht löst

Canary-Deployments und gestaffelte Rollouts lösen ein Problem gut: Sie steuern, wie viel Traffic eine neue Version Ihrer Anwendung erreicht. Sie leiten 5 % der User auf die neue Version, beobachten Fehler und erhöhen dann auf 100 %. Das funktioniert, wenn Sie eine gesamte Version schrittweise ausrollen möchten.

Aber was, wenn Sie ein bestimmtes Feature nur für bestimmte User aktivieren wollen, ohne verschiedene Code-Versionen zu deployen? Vielleicht sollen interne Tester die neuen Suchergebnisse sehen, während alle anderen beim alten Algorithmus bleiben. Vielleicht möchten Sie ein Feature zuerst nur für User in einer Region freischalten. Vielleicht wollen Sie einen neuen Checkout-Prozess mit 10 % der User testen, aber nur, wenn sie die Mobile App nutzen.

Canary- und gestaffelte Rollouts lösen das nicht. Sie arbeiten auf Versionsebene, nicht auf Feature-Ebene. Sie brauchen etwas, das innerhalb Ihres Codes lebt und Entscheidungen pro Request, pro User, pro Session trifft.

Feature Flags: Eine Steuerungsebene im Code

Feature Flags sind bedingte Prüfungen in Ihrem Code, die bestimmen, ob ein Feature für einen bestimmten User aktiv sein soll. Der entscheidende Punkt: Die Bedingung basiert nicht darauf, welche Code-Version läuft. Sie basiert auf einer Konfiguration, die sich jederzeit ohne erneutes Deployment ändern lässt.

So sieht das in der Praxis aus. Ihr Team schließt den neuen Suchalgorithmus ab. Der Code wird als Teil der neuesten Version in Produktion deployed. Aber innerhalb der Suchfunktion gibt es eine Prüfung:

Hier ein JavaScript-Beispiel für dasselbe Muster:

const featureFlags = require('./feature-flags');

function search(query, user) {
  if (featureFlags.isEnabled('new-search', user)) {
    return newSearchAlgorithm(query);
  } else {
    return oldSearchAlgorithm(query);
  }
}

// Das Flag ist standardmäßig deaktiviert, alle User nehmen den alten Pfad.
// Wenn bereit, Flag für Tester über das Dashboard aktivieren.

if feature_flag.is_active("new_search_algorithm", user):
    return new_search_algorithm(query)
else:
    return old_search_algorithm(query)

Das Flag ist standardmäßig deaktiviert. Jeder User bekommt weiterhin den alten Algorithmus, obwohl der neue Code auf demselben Server liegt. Wenn Sie bereit sind, schalten Sie das Flag für interne Tester ein. Sie sehen die neuen Ergebnisse. Sie beobachten ihr Verhalten. Wenn etwas schiefläuft, schalten Sie das Flag wieder aus. Kein Rollback. Kein erneutes Deployment. Nur eine Konfigurationsänderung, die in Sekunden wirkt.

Warum Deployment und Release trennen?

Der erste Vorteil ist psychologisch und praktisch zugleich: Deployment hört auf, ein Hochrisiko-Event zu sein. Wenn jedes Deployment alle Änderungen sofort aktiviert, bündeln Sie Arbeit, testen intensiv und halten während Release-Fenstern den Atem an. Wenn Deployment und Release getrennt sind, können Sie täglich oder mehrmals täglich deployen, im Wissen, dass neuer Code ruht, bis Sie ihn explizit einschalten.

Der zweite Vorteil ist granulare Kontrolle. Feature Flags sind nicht einfach nur an oder aus für alle. Sie können Targeting-Regeln definieren:

• Aktiv für User mit bestimmten IDs
• Aktiv für User in bestimmten Regionen
• Aktiv für interne Tester oder Beta-User
• Aktiv für einen Prozentsatz aller User

Diese Regeln lassen sich stapeln. Sie könnten mit 5 % der User starten, einen Tag beobachten, auf 25 % erhöhen, dann auf 50 %, dann auf 100 %. Jede Änderung erfolgt über ein Dashboard oder einen API-Aufruf. Keine Code-Änderungen. Keine Deployments.

Der dritte Vorteil ist der Kill-Switch. Wenn ein Feature nach der Aktivierung Probleme verursacht, können Sie es von einer zentralen Stelle aus deaktivieren. Das ist viel schneller, als auf den Abschluss einer Rollback-Pipeline zu warten. In Sekunden ist das problematische Feature aus, und User fallen auf das alte Verhalten zurück. Bei Produktionsvorfällen zählen diese Sekunden.

Die versteckten Kosten: Flag-Schulden

Feature Flags erhöhen die Komplexität Ihrer Codebasis. Jedes Flag führt einen bedingten Zweig ein, der gewartet werden muss. Wenn Ihr Team Flags erstellt und nie entfernt, füllt sich Ihr Code mit toten Bedingungen, an die sich niemand erinnert.

Ein typisches Szenario: Ein Feature Flag wird für einen neuen Checkout-Prozess erstellt. Der Prozess wird erfolgreich auf 100 % der User ausgerollt. Der alte Checkout-Code existiert noch, geschützt durch ein Flag, das immer aus ist. Monate später sieht ein neuer Entwickler das Flag und fragt sich, ob es noch relevant ist. Niemand weiß es. Das Flag bleibt, weil das Entfernen riskant erscheint.

Das sind Flag-Schulden, und sie sind die Hauptbetriebskosten von Feature Flags. Flags brauchen einen Lebenszyklus: erstellen, aktivieren, überwachen, aufräumen. Wenn ein Feature vollständig an alle User ausgerollt ist, sollten der alte Codepfad und das Flag entfernt werden. Das Flag hat seinen Zweck erfüllt. Es zu behalten erhöht nur die kognitive Last und vergrößert die Angriffsfläche für Fehler.

Den richtigen Flag-Management-Ansatz wählen

Für kleine Teams oder einfache Anwendungsfälle können Feature Flags als Umgebungsvariablen oder Konfigurationsdateien beginnen, die die Anwendung beim Start liest. Das funktioniert, hat aber eine Einschränkung: Das Ändern eines Flags erfordert einen Neustart oder ein erneutes Laden der Konfiguration.

Für größere Teams oder komplexere Targeting-Regeln bieten dedizierte Flag-Management-Plattformen wie LaunchDarkly, Split oder Flagr Echtzeit-Flag-Auswertung, User-Targeting und Audit-Logs. Diese Plattformen ermöglichen es, Flags über ein Dashboard zu ändern und die Wirkung sofort auf allen laufenden Instanzen zu sehen.

Die richtige Wahl hängt von Ihrer Skalierung ab. Starten Sie einfach. Fügen Sie Komplexität nur hinzu, wenn Sie sie brauchen.

Praktische Checkliste für den Einsatz von Feature Flags

• Jedes Flag hat einen klaren Besitzer und Zweck, dokumentiert an einer sichtbaren Stelle
• Flags haben ein geplantes Entfernungsdatum oder eine Auslösebedingung (z. B. „entfernen, wenn Rollout 100 % erreicht“)
• Alte Codepfade werden entfernt, wenn das Flag nicht mehr benötigt wird
• Flag-Änderungen werden protokolliert mit Angabe, wer was wann geändert hat
• Kritische Flags haben ein Monitoring-Dashboard, das zeigt, wer welche Variante sieht
• Das Team hat einen regelmäßigen Rhythmus zum Bereinigen veralteter Flags

Das Fazit

Feature Flags geben Ihnen eine Steuerungsebene, die unabhängig von Ihrer Deployment-Pipeline arbeitet. Canary- und gestaffelte Rollouts steuern, wie viel Traffic eine neue Version erreicht. Feature Flags steuern, welche User welche Features innerhalb derselben Version sehen. Nutzen Sie beide zusammen, erhalten Sie feingranulare Kontrolle darüber, wie Änderungen Ihre User erreichen. Denken Sie nur daran: Jedes Flag, das Sie erstellen, ist ein Stück technische Schuld, das bereinigt werden muss, wenn seine Aufgabe erledigt ist.