In vielen Teams ist ein Deployment gleichbedeutend mit einem Release: Sobald Code live ist, sehen alle Nutzer die neue Funktion. Feature Flags lösen diese Kopplung. Code kann ausgeliefert werden, bevor eine Funktion sichtbar ist, und sichtbar werden für wen und wann man will.
Arten von Flags
Release-Flags verstecken unfertige Funktionen, bis sie bereit sind, und werden danach entfernt. Experiment-Flags vergleichen Varianten. Operative Flags dienen als Kill-Switch, um eine fehlerhafte oder teure Funktion sofort abzuschalten, etwa eine KI-Funktion bei explodierenden Kosten. Berechtigungs-Flags schalten Funktionen pro Plan, Mandant oder Nutzergruppe frei und sind oft dauerhaft.
Schrittweise Rollouts
Eine neue Funktion wird zuerst intern aktiviert, dann für einzelne Pilotkunden, dann für einen Prozentsatz der Nutzer, schliesslich für alle. Zeigen Observability-Daten Probleme, wird zurückgeschaltet, ohne Rollback des Codes. Das senkt das Risiko jedes Releases und erlaubt häufigere Deployments über die CI/CD-Pipeline.
Umsetzung in SaaS
Die einfachste Form ist eine Konfiguration pro Mandant in der Datenbank, die serverseitig ausgewertet wird. Für komplexere Regeln gibt es Dienste und offene Standards wie OpenFeature. Wichtig ist, dass Flags serverseitig geprüft werden, wenn sie Zugriff auf Daten oder Funktionen steuern; ein nur im Frontend verstecktes Feature ist kein geschütztes Feature. Bei Mandantenfähigkeit gehört der Flag-Status zum Mandanten und nicht zum einzelnen Browser.
Flag-Schulden
Jeder Flag ist eine Verzweigung im Code und damit eine Testvariante. Release-Flags, die nach dem Rollout nicht entfernt werden, sammeln sich an und machen den Code unübersichtlich. Bewährt haben sich ein Ablaufdatum oder eine verantwortliche Person pro Flag und eine regelmässige Bereinigung. Dauerhafte Berechtigungs-Flags gehören dagegen sauber in das Modell von Plänen und Rechten.
Wann sie sich lohnen
Schon kleine Teams profitieren von einem Kill-Switch für riskante Funktionen und von Pilotfreischaltungen für einzelne Kunden. Ein vollständiges Experimentier-Framework lohnt sich erst mit genügend Nutzern für aussagekräftige Vergleiche. Für ein neues Produkt reicht oft eine Tabelle mit Flags pro Mandant, sauber serverseitig geprüft — das bauen wir in unseren SaaS-Launch-Paketen von Anfang an ein.