Feature Flag.
Ein Feature Flag ist ein Schalter im Code, mit dem eine Funktion ein- oder ausgeschaltet wird, ohne die Software neu auszuliefern. So lässt sich eine neue Funktion zuerst nur für das eigene Team, dann für einen Teil der Nutzer und erst danach für alle freigeben, und bei Problemen wird sie mit einem Klick wieder abgeschaltet.
Feature Flag — ausführlich erklärt
Ein Feature Flag (auch Feature Toggle oder Feature-Schalter) trennt zwei Dinge, die in klassischer Softwareentwicklung zusammenfallen: das Ausliefern von Code und das Freischalten einer Funktion. Der neue Code ist bereits auf dem Server, aber eine einfache Abfrage entscheidet, ob er ausgeführt wird. Der Wert dieses Schalters liegt ausserhalb des Codes, etwa in einer Konfigurationsdatei, einer Umgebungsvariable, einer Datenbanktabelle oder einem spezialisierten Dienst. Wer ihn umlegt, ändert das Verhalten der Anwendung sofort, ohne neuen Build und ohne neues Deployment.
Man unterscheidet grob vier Arten. Release-Flags verstecken halbfertige Funktionen, damit das Team weiter in den Hauptzweig der Versionskontrolle arbeiten kann, statt wochenlang getrennte Zweige zu pflegen. Experiment-Flags teilen Nutzer in Gruppen auf und sind die technische Grundlage für A/B-Tests. Ops-Flags sind Notschalter, die eine rechenintensive oder fehleranfällige Funktion bei Last abschalten. Berechtigungs-Flags schalten Funktionen nur für bestimmte Kunden, Pakete oder Rollen frei, etwa einen Export, der nur im grösseren Abo enthalten ist.
Der grösste praktische Nutzen ist die schrittweise Freigabe. Eine neue Funktion läuft zuerst nur für interne Konten, dann für fünf Prozent der Nutzer, dann für alle. Zeigen sich Fehler, wird nicht hektisch zurückgerollt, sondern der Schalter umgelegt. Das senkt das Risiko jedes Releases und erlaubt, öfter und in kleineren Schritten auszuliefern. Zusammen mit einer Staging-Umgebung entsteht so ein ruhiger Ablauf: testen auf Staging, ausliefern in Produktion hinter dem Schalter, kontrolliert freigeben.
Feature Flags haben eine Schattenseite: Jeder Schalter verdoppelt die Pfade, die der Code nehmen kann. Werden alte Flags nach der vollständigen Freigabe nicht entfernt, wächst die Zahl der möglichen Kombinationen, Tests werden unübersichtlich und niemand weiss mehr, welcher Schalter noch etwas bewirkt. Das ist eine typische Form technischer Schuld. Gute Praxis ist deshalb, jedem Release-Flag beim Anlegen ein Ablaufdatum und eine verantwortliche Person zu geben. Wie wir Web-Apps mit sauberem Release-Prozess bauen, zeigt die Seite Web-App entwickeln lassen.
Feature Flags selbst bauen oder als Dienst nutzen?
Für ein kleines Produkt genügt oft eine schlichte Lösung: eine Tabelle mit Schaltern in der eigenen Datenbank und eine kleine Admin-Oberfläche, um sie umzulegen. Das ist schnell gebaut, kostet nichts im Betrieb und bleibt vollständig unter eigener Kontrolle. Sobald prozentuale Freigaben, Zielgruppen nach Merkmalen, Auswertungen und ein Änderungsprotokoll gebraucht werden, lohnt ein spezialisierter Dienst oder eine Open-Source-Lösung, die man selbst betreibt.
Bei Diensten von Drittanbietern ist zu prüfen, welche Nutzerdaten für die Zielgruppen-Regeln übermittelt werden und wo sie verarbeitet werden. Für Schweizer Unternehmen ist das eine Frage des Datenschutzgesetzes. Die Entscheidung folgt derselben Logik wie jede Make-or-buy-Frage: Wie zentral ist die Funktion, und wie viel Abhängigkeit ist vertretbar?
Beispiel: Neue Online-Buchung für einen Coiffeursalon
Ein Beispiel: Ein Coiffeursalon mit drei Filialen lässt seine Buchungs-App um eine Anzahlung per Karte erweitern. Statt die Funktion an einem Montagmorgen für alle Kundinnen freizuschalten, wird sie hinter ein Feature Flag gelegt. In der ersten Woche sehen sie nur die Mitarbeitenden, die selbst Testbuchungen machen. In der zweiten Woche wird sie für eine einzige Filiale aktiviert, damit das Team lernt, wie es mit Rückfragen umgeht.
Zeigt sich in dieser Phase, dass die Bestätigungs-E-Mail bei bestimmten Mailprogrammen falsch dargestellt wird, wird die Anzahlung für diese Filiale per Schalter wieder deaktiviert, der Fehler behoben und die Freigabe neu gestartet. Erst wenn alles stabil läuft, gilt die Funktion für alle drei Filialen, und das Flag wird aus dem Code entfernt. Solche Abläufe planen wir bei Individualsoftware und bei der Webentwicklung in Zürich von Anfang an mit.
Weiterführende Seite
Technische SchuldHäufige Fragen zu Feature Flag
Eine Konfiguration beschreibt dauerhafte Einstellungen einer Anwendung, etwa die Adresse des Mailservers. Ein Feature Flag ist in der Regel vorübergehend und steuert, ob eine bestimmte Funktion für wen sichtbar ist. Technisch können beide am selben Ort liegen; der Unterschied ist der Zweck und die Lebensdauer.
Nein. Schon ein einzelner Schalter, der eine neue Funktion zuerst nur für das eigene Team sichtbar macht, senkt das Risiko eines Releases deutlich. Für kleine Projekte reicht eine einfache Lösung in der eigenen Datenbank; ein spezialisierter Dienst lohnt sich erst bei vielen Schaltern und Zielgruppen.
Release-Flags sobald die Funktion für alle freigegeben ist und stabil läuft, meist nach wenigen Wochen. Dauerhafte Flags, etwa für Paket-Berechtigungen oder Notschalter, bleiben bestehen, sollten aber dokumentiert sein. Ein Flag ohne Ablaufdatum und ohne verantwortliche Person wird mit hoher Wahrscheinlichkeit vergessen.
Weitere Begriffe mit „F“
FCP (First Contentful Paint)
FCP misst, wie lange es dauert, bis der erste sichtbare Inhalt (Text, Bild, SVG) im Browser erschein...
First-Party Data
First-Party Data sind Daten, die ein Unternehmen direkt von seinen eigenen Kunden und Website-Besuch...
Funnel (Marketing Funnel)
Ein Marketing Funnel (Trichter) visualisiert die Customer Journey von der ersten Berührung bis zum K...
Bereit für Ihr Projekt?
Wenden Sie dieses Wissen auf Ihre Website an — DLM Digital hilft Ihnen dabei.