Feature Toggles sind eines dieser Konzepte, die auf den ersten Blick einfach klingen, aber in der Praxis enormes Potenzial entfalten. In dieser Session des DevOps Meetup Zürich spreche ich gemeinsam mit Ben Rometsch, dem Gründer von Flagsmith, über das Was, Warum und Wie von Feature Toggles. Wir behandeln die grundlegenden CI/CD-Konzepte, die Feature Toggles notwendig machen, den Unterschied zwischen Deployment und Release, und wie moderne Feature-Flagging-Plattformen progressive Rollouts, User-Segmentierung und A/B Testing ermöglichen.
Die Grundlage: CI/CD#
Bevor wir über Feature Toggles sprechen können, müssen wir ein paar Grundlagen verstehen. Continuous Integration (CI) bedeutet, dass jedes Mal, wenn Code committed wird, dieser mit dem restlichen Code reintegriert wird. Der CI-Server baut den Code, führt statische Code-Analyse durch, macht statische Security-Analyse, führt Unit Tests und Integrationstests aus. Das Ergebnis ist ein deployierbares Artefakt. Das Wichtigste dabei: Das Feedback muss den Entwickler so schnell wie möglich erreichen, innerhalb von Minuten, nicht Stunden.
Continuous Delivery baut auf CI auf. Das deployierbare Artefakt wird automatisch in eine Staging-Umgebung deployt, eine produktionsnahe Umgebung, in der Acceptance Testing und exploratives Testen stattfinden können. Continuous Deployment geht noch einen Schritt weiter: Das Artefakt fliesst automatisch durch alle Quality Gates in die Produktion. Eine Zeile Code ändern, committen, und sie fliesst den ganzen Weg bis in die Produktion.
“Es gibt nichts Nervigeres, als Code zu committen und zwei Stunden später das Feedback zu bekommen. Bis dahin arbeitet man längst an etwas völlig anderem.”
Das Schlüsselkonzept: Deployment von Release trennen#
Das ist das fundamentale Konzept, das Continuous Deployment ermöglicht: die Trennung von Deployment und Release.
Ein Deployment bedeutet, den kompilierten Code in die Produktion zu bringen, mit dem Feature Toggle ausgeschaltet. Ein Release bedeutet, den Feature Toggle einzuschalten und den Nutzern Zugang zur neuen Funktionalität zu geben. Durch die Trennung dieser beiden Konzepte kann man kontinuierlich in die Produktion deployen, ohne unfertigen Nutzer Features anzuzeigen.
Dark Launches#
Wenn man Code in die Produktion deployt, mit dem Feature Toggle ausgeschaltet, führt man einen “Dark Launch” durch. Die Funktionalität ist bereits in der Produktion, aber für die Nutzer unsichtbar. Das gibt einem die Möglichkeit, das Monitoring und Alerting aufzusetzen und zu prüfen, wie der neue Code unter realer Last mit dem Live-System interagiert.
Das bekannteste Beispiel ist der Facebook Messenger. Ein ganzes Jahr vor dem offiziellen Release war der Facebook Messenger bereits in der Produktion, versteckt hinter Feature Flags. Facebook nutzte dieses Jahr, um Monitoring und Alerting anzuschliessen und zu beobachten, wie der Messenger sich unter Facebooks massiver Last verhält. Am Tag des Releases mussten sie nur den Toggle umschalten, und alles funktionierte.
Was genau ist ein Feature Toggle?#
Im Kern ist ein Feature Toggle nichts anderes als eine if-Anweisung: Wenn das Flag true ist, wird der neue Code-Pfad ausgeführt. Wenn das Flag false ist, wird der alte Code-Pfad ausgeführt. Das ist das gesamte Konzept.
Eine wichtige Unterscheidung: Ein Feature Toggle ist keine Anwendungskonfiguration. Anwendungskonfigurationen sind permanente Einstellungen der Anwendung. Ein Feature Toggle ist temporär. Er existiert nur, um Continuous Deployment oder Dark Launches zu ermöglichen. Sobald das Feature released und stabil ist, entfernt man den Toggle aus dem Code.
“Feature Toggles im Blick behalten. Wenn man das nicht tut, verbreiten sie sich überall, führen zu unübersichtlichem Code und erheblichen technischen Schulden.”
Ein Wort der Warnung: Jeder Feature Toggle, den man hinzufügt, ist im Grunde ein Testfall. Wenn man zu viele aktive Toggles hat, wächst die kombinatorische Komplexität schnell. Man sollte sie mit Bedacht einsetzen und immer aufräumen, nachdem das Feature released wurde.
Feature Flags im grossen Stil verwalten#
Für einen einzelnen Toggle reichen eine einfache if-Anweisung und eine Wiki-Seite vielleicht aus. Im grossen Stil braucht man aber richtiges Tooling. Plattformen wie Flagsmith, ein Open-Source Feature-Flagging-Tool, bieten Dashboards, um Flags über Umgebungen hinweg zu verwalten, zu steuern wer was sieht und sich mit Analytics-Anbietern zu integrieren.
Ben Rometsch hat in einer Live-Demo gezeigt, wie Flagsmith in der Praxis funktioniert:
- Flags auf Umgebungsebene: Ein Flag erstellen, in der Entwicklungsumgebung aktivieren, in der Produktion deaktiviert lassen. So können Entwickler Features in der Entwicklungsumgebung testen, während die Produktion stabil bleibt.
- Überschreibungen auf Nutzerebene: Ein Flag für einen bestimmten Nutzer in der Produktion aktivieren. So kann ein Entwickler den neuen Checkout-Flow in der Produktion testen, während alle anderen den alten sehen.
- Segmentbasierte Rollouts: Regeln basierend auf Nutzer-Merkmalen (Alter, Standort, Tarif) definieren, um zu steuern, welche Nutzergruppen ein Feature sehen.
- Prozentuale Rollouts: Ein Feature zuerst an 1% der Nutzer ausrollen, auf Probleme prüfen, dann schrittweise auf 50% und schliesslich 100% erhöhen.
Progressive Enhancement und Resilienz#
Ein wichtiges Designprinzip: Die Anwendung muss sich auch dann korrekt verhalten, wenn die Feature-Flagging-API nicht erreichbar ist. Das liegt nicht daran, dass die API ausfällt, sondern weil Nutzer unzuverlässige Netzwerke haben, seltsame Ad-Blocker nutzen oder gerade in einen Tunnel gefahren sind. Immer ein Standardverhalten designen, das auch ohne die Flags der Plattform funktioniert.
Von Feature Flags zu Experimentation#
Sobald Feature Flags im Einsatz sind, wird A/B Testing fast gratis. Man kann 50% der Nutzer den neuen Checkout-Flow zeigen und 50% den alten, und dann messen, welcher besser performt. Man geht vom “Testen in der Produktion als Entwickler” zum “A/B-Test gegen die Plattform” mit nur wenigen Klicks, und ohne Code-Änderungen.
“Der heilige Gral ist es, den Kreislauf zu schliessen: vom Schreiben des Feature-Codes bis hin zur Generierung von Daten über die Wirksamkeit dieses Features.”
Kernaussagen#
Deployment von Release trennen. Das ist das fundamentale Konzept, das Continuous Deployment ermöglicht. Mit ausgeschaltetem Toggle deployen, durch Einschalten releasen.
Feature Toggles sind temporär. Sie sind keine Anwendungskonfigurationen. Entfernen, sobald das Feature released und stabil ist.
Dark Launches reduzieren Risiko. Code in die Produktion zu deployen, bevor er released wird, ermöglicht es, Monitoring aufzusetzen und das Verhalten unter realer Last zu prüfen.
Einfach starten, schrittweise wachsen. Mit einfachen An/Aus-Flags beginnen. Dann zu Überschreibungen auf Nutzerebene, segmentbasierten Rollouts und schliesslich A/B Testing übergehen.
Toggles aufräumen. Jeder nicht entfernte Toggle fügt Komplexität und potenzielle technische Schulden hinzu. Konsequent tracken und entfernen.
Für Resilienz designen. Die Anwendung muss sich korrekt verhalten, auch wenn der Feature-Flag-Service nicht erreichbar ist.