Toggles für experimentelle und neue Funktionen Schlankes Entwickeln mit Feature Flags

Anbieter zum Thema

DAXTEN GmbH

Fsas Technologies GmbH

Data Center Group – Büro Köln

Feature Flags sind äußerst nützlich. Developer können sich mit ihnen von Merge-Konflikten in Git befreien, Bleeding-Edge-Funktionen ausrollen, Bugs behandeln und viele Stunden Compiler-Zeit einsparen.

Feature Flags, bisweilen auch (noch) Feature Toggles genannt, sind ein wunderbares Konzept zum Ein- und Ausschalten von Features zur Laufzeit eines Services. Das klingt vielleicht etwas abstrakt, ist aber im Grunde genauso nützlich wie simpel umzusetzen.

In letzter Zeit hört man von Feature Flags vor allem im Zusammenhang mit Trunk Based Development (TBD), einem bestimmten Git-Workflow, der eine Alternative zum etablierten Feature-Branching sein kann. Sie finden bei uns auch eine Übersicht der wichtigsten Git-Workflows sowie eine Vertiefung zum Thema TBD.

Hier daher nur die Kurzfassung: Statt für jedes Feature einen eigenen Branch anzulegen, setzt TBD auf nur einen einzigen Branch. Auf diesem Weg lassen sich Probleme und Arbeitslasten durch Merge-Konflikte reduzieren. Stattdessen werden Feature Flags genutzt, über die unfertige Funktionen schlicht deaktiviert werden. Für die User macht es keinen Unterschied, ob sie eine Funktion nicht sehen, weil der Branch nicht ins Release gewandert ist oder weil das Feature einfach nur nicht sichtbar ist.

Schlankere Entwicklung ist aber nur ein möglicher Vorteil. Da Feature Flags zur Laufzeit ansetzen, lassen sich zum Beispiel experimentelle Features „mal eben“ ausprobieren oder verbuggte Features deaktivieren, ohne diese gleich Code-seitig beheben oder ein neues Release bauen zu müssen.

Die Umsetzung kann dabei simpel sein: Ein externes Dokument oder eine Datenbank enthält eine Liste mit Features und einem zugehörigen Status (aktiv/inaktiv), der Service liest diese Daten ein und im Code werden dann Features gemäß Status ausgeliefert oder nicht. Ein – extrem – simples Beispiel soll das Konzept im Folgenden verdeutlichen.

Beispiel: Bash

Nehmen wir ein einfaches Bash-Skript, das nur ein einziges Feature hat: Es gibt Namen und Status von aktivierten Features aus, gemäß der in der Datei „flags“ gesetzten Feature Flags. Zunächst das Skript:

Und hier der Inhalt der Datei „flags“:

Und noch die Ausgabe:

Natürlich ist die reine Ausgabe eines Status nicht sonderlich spannend und hier werden die Feature Flags nur beim Programmstart ausgewertet –, aber grundsätzlich ist es tatsächlich so trivial. Das ganze Konzept beschränkt sich in diesem Beispiel also auf die Auswertung einer externen Config-Datei über eine simple if-Abfrage. Die drei deaktivierten Features spielen im Programmablauf aus Nutzersicht keine Rolle.

Nun, eine kleine Einschränkung muss natürlich her: Die deaktivierten Features werden natürlich geparst und würden auch in einer kompilierten Version berücksichtigt werden müssen. Aus diesem simplen Beispiel ließe sich dennoch recht schnell eine fast schon praxistaugliche Anwendung stricken – mit drei simplen Maßnahmen.

• Zunächst könnte man die Config-Datei in ein strukturiertes Datenformat wie JSON überführen, was ein zuverlässiges Parsen ermöglicht (etwa mit jq).

• Dann sollte solche eine Feature-Flag-Datei freilich nicht lokal beim Anwender liegen, sondern zentral beim Anbieter, etwa in einem Git-Repository. Die Abfrage ließe sich auf Scripting-Ebene zum Beispiel mit einem simplen curl-Befehl erledigen.

• Und letztlich sollte die Abfrage der Flaggen nicht an den Programmstart gebunden sein, sondern an Events im Programm, etwa den Aufruf eines Features, das über eine Feature Flag verwaltet wird.

Feature Flags in der Realität

Kommen wir zum Thema Git zurück. Hier bieten sich Feature Flags für das Continuous Deployment an. Beim Betreiben einer Website via GitHub Pages ließen sich mit diesem Konzept schnell experimentelle Features testen, aber auch aktuelle Hinweise setzen oder fehlerhafte Beiträge verstecken.

Schnell kommen dabei Begehrlichkeiten auf: Sollen vielleicht nur einige Besucherinnen und Besucher mit experimentellen Funktionen konfrontiert werden? Oder gar nur angemeldete Personen aus dem Projekt selbst? Wie lassen sich die Marker sinnvoll verwalten und möglicherweise sogar tracken? Oder anders gefragt: Gibt es das nicht „fertig“?

Natürlich gibt es allerlei Tools rund um Feature Flags, teils Spezialisten, teils einzelne Funktionen in umfangreicheren Software-Plattformen. Erfreulicherweise hat auch die Open-Source-Welt einiges zu bieten.

So finden sich Feature Flags seit einiger Zeit zum Beispiel in der Open-Source-Edition von PostHog. Das Projekt bezeichnet sich selbst als „Produkt-Analyse- und Experimentier-Plattform“ und stellt einige nützliche Services rund um Statistiken, Nutzeranalyse und Testing zur Verfügung. Ein Highlight ist dabei sicherlich, Screenvideos von Nutzer-Sessions aufzeichnen zu können, samt hübscher Cursor-Visualisierung – was sogar schon in der freien Version funktioniert.

Die Umsetzung von Feature Flags ist angenehm unkompliziert geraten und zum Beispiel für bestehende Webseiten sehr schnell aufgesetzt. Die Anbindung einer Website an PostHog ist trivial: Nach der Anmeldung erhält der User einen JavaScript-Code-Schnipsel, der in den Header der Seite eingebaut wird. Statistiken und Session-Videos stehen dann umgehend zur Verfügung.

Um ein Feature Flag anzulegen, gilt es, den entsprechenden Punkt in der Hauptnavigation und dann „New Feature Flag“ auswählen. Für die Grundfunktion genügt es, hier einen sinnvollen Namen bzw. Key zu vergeben.

Optional lassen sich Feature Flags über etwaige Nutzer-Authentifizierungen persistent machen, damit die Wirksamkeit auch nach einer Anmeldung erhalten bleibt. Man denke da etwa an Online-Shops, wo es normal ist, dass erst gestöbert, dann angemeldet und gekauft wird. Auf Wunsch lassen sich sogar individuelle Payloads zur Auswertung setzen.

Spannend sind aber eher die „Release Conditions“: Hier lassen sich Filter für den Einsatz der Feature Flag setzen. Diese können eine Bereitstellung beispielsweise auf bestimmte Geräte, Betriebssysteme, Browser, Nutzer und so weiter beschränken. Ebenso lässt sich festlegen, wie viel Prozent der gefilterten Nutzer dann letztlich in den Genuss bestimmter Features kommen.

Einmal gesetzt, muss das Feature Flag natürlich noch in das eigene Projekt eingebaut werden. Dafür wird wiederum ein Code-Snippet bereitgestellt, wahlweise für PHP, Ruby, Golang, Node.JS, API oder JavaScript, hier für eine Feature Flag namens „ml_1“:

Das Einbinden von Feature Flags läuft also auch in der Praxis auf eine simple if-Abfrage hinaus. Die Abrufe der Flagge werden unter dem Punkt „Usage“ (noch eine Beta-Funktion) detailliert protokolliert.

Natürlich ist PostHog nicht auf diese genaue Vorgehensweise beschränkt. Dies gilt vor allem für die Nutzung der Client-Bibliothek, die in diesem Fall über das Header-JavaScript-Snippet angesprochen wird und bei PostHog liegt. Bibliotheken gibt es auch für diverse SDKs, etwa Android, iOS, Python oder Rust.

PostHog sollte hier aber nur als besonders zugängliches Beispiel für Anbieter von Feature Flag Managment dienen, es gibt etliche weitere Kandidaten, die ebenfalls in freien Versionen erhältlich sind, etwa Flagsmith, Unleash oder Growthbook; und Jira unterstützt ebenfalls diverse Feature-Flagging-Kandidaten.

(ID:49251733)