Feature Flag

Wenn ein Entwicklerteam eine neue Funktion in eine App einbaut, muss diese Funktion nicht sofort für alle sichtbar sein. Man kann sie stattdessen hinter einen Schalter legen. Dieser Schalter ist ein Feature Flag: eine Stelle im Programmcode, die abfragt, ob die neue Funktion gerade erlaubt ist oder nicht. Steht der Schalter auf „aus“, verhält sich die App so wie vorher. Steht er auf „an“, erscheint die Neuerung. Umgelegt wird der Schalter von außen, über eine zentrale Einstellung, und zwar im laufenden Betrieb.

Warum große Anbieter ohne Schalter nicht mehr arbeiten

Früher wurde Software in großen Paketen veröffentlicht, oft nur wenige Male im Jahr. Heute liefern viele Firmen mehrmals täglich neue Versionen aus. Dabei wächst das Risiko, dass eine Änderung Fehler verursacht. Ein Feature Flag trennt zwei Dinge, die vorher fest zusammenhingen: das Ausliefern des Codes und das Freigeben der Funktion für Nutzer. Der Code liegt schon auf den Servern, aber niemand merkt etwas davon.

Der praktische Gewinn zeigt sich im Notfall. Wenn eine neue Bezahlfunktion Fehler produziert, muss niemand hektisch eine korrigierte Version bauen. Ein Klick stellt den Schalter zurück, und Sekunden später ist der alte Zustand wieder da. Ohne Flags dauert so eine Rücknahme im schlechten Fall Stunden.

Dazu kommt der wirtschaftliche Aspekt. Firmen wollen wissen, ob eine Neuerung überhaupt etwas bringt, bevor sie sie überall ausrollen. Mit einem Flag kann man die Funktion für zwei Prozent der Nutzer anschalten und die Zahlen mit dem Rest vergleichen. Das nennt man einen A/B-Test: zwei Gruppen, ein Unterschied, danach ein Vergleich der Ergebnisse.

Vom Schalter zur Regel im Code

Technisch ist ein Feature Flag im einfachsten Fall eine Wenn-Abfrage. Der Code fragt: Ist die Funktion „neue Suche“ für diesen Nutzer aktiv? Wenn ja, wird der neue Programmteil ausgeführt, sonst der alte. Die Antwort steht nicht im Code selbst, sondern kommt von einem Dienst, der alle Schalter des Unternehmens verwaltet.

Interessant wird es, weil die Antwort pro Nutzer unterschiedlich ausfallen kann. Die Regel kann lauten: an für alle Mitarbeiter, an für fünf Prozent aller übrigen Nutzer, aus für den Rest. So lässt sich eine Funktion stufenweise ausrollen, erst intern, dann für eine kleine Testgruppe, dann für alle. Man beobachtet nach jeder Stufe, ob Fehlerzahlen oder Ladezeiten schlechter werden.

Der typische Irrtum ist, Flags für harmlos zu halten. Jeder Schalter verdoppelt gedanklich die Zahl möglicher Zustände der Software. Zehn Flags ergeben theoretisch über tausend Kombinationen, die alle funktionieren müssten. Deshalb gilt als Regel: Ein Flag, das seinen Zweck erfüllt hat, wird samt altem Code entfernt. Vergessene Flags sind eine bekannte Quelle für schwer erklärbare Fehler.

Feature Flags bei KI-Funktionen und in Firmenmeldungen

Als Nutzer bemerkt man Feature Flags meist nur indirekt. Ein Freund hat in derselben App schon die neue Oberfläche, du noch nicht, obwohl beide dieselbe Version installiert haben. Genau das ist ein Flag bei der Arbeit. Auch Meldungen wie „die Funktion wird in den nächsten Wochen ausgerollt“ beschreiben nichts anderes als einen Schalter, der schrittweise weiter aufgedreht wird.

Bei KI-Produkten spielen Flags eine besonders große Rolle. Ein neues Sprachmodell in einem Chat-Dienst ist teuer im Betrieb und im Verhalten schwer vorhersagbar. Anbieter schalten es deshalb zuerst für eine kleine Gruppe frei und vergleichen Antwortqualität, Kosten und Beschwerden. Fällt das Ergebnis schlecht aus, geht der Schalter zurück, oft ohne dass es öffentlich bemerkt wird.

In Finanz- und Tech-News tauchen Flags meist zwischen den Zeilen auf. Wenn ein Unternehmen berichtet, ein Fehler sei „innerhalb von Minuten behoben“ worden, steckt fast immer ein zurückgestellter Schalter dahinter. Und wenn eine angekündigte Funktion monatelang nicht erscheint, liegt sie oft längst im Code, nur eben abgeschaltet.