Feature Flags und Trunk-Based Development

Die meisten Teams, die Mühe mit der Auslieferung haben, sind nicht langsam, weil ihre Ingenieurinnen und Ingenieure langsam wären. Sie sind langsam, weil ihre Branches wochenlang leben, ihre Merges beängstigend sind und jedes Release ein Big-Bang-Ereignis ist, das jemand um 2 Uhr morgens betreuen muss. Trunk-Based Development und Feature Flags greifen dieses Problem von zwei Seiten an: den Code kontinuierlich integriert halten und den Moment des Deployments vom Moment des Aktivierens einer Funktion trennen.

Gut umgesetzt ist diese Kombination der stille Motor hinter Teams, die viele Male am Tag ausliefern, bei ruhiger Rufbereitschaft. Unachtsam umgesetzt verwandelt sie Ihre Codebasis in ein Labyrinth veralteter Schalter, die sich niemand zu löschen traut. Dieser Leitfaden behandelt beide Seiten ehrlich.

Deployment ist nicht Release

Der nützlichste Gedanke hier ist, dass das Deployen von Code und das Releasen einer Funktion zwei verschiedene Ereignisse sind und dass Sie in der Lage sein sollten, das eine ohne das andere zu tun.

Im alten Modell sind sie zusammengeschweißt. Der Code erreicht die Produktion, und in diesem Augenblick sehen die Nutzerinnen und Nutzer das neue Verhalten. Diese Kopplung macht Releases beängstigend, denn die einzige Möglichkeit, in einer realen Umgebung zu testen, besteht darin, alle auf einmal auszusetzen, und die einzige Möglichkeit, ein schlechtes Release rückgängig zu machen, ist ein erneutes Deployment.

Trennen Sie die beiden, und die Angst verfliegt. Der Code geht dunkel in Produktion, eingehüllt in ein ausgeschaltetes Flag. Er liegt dort, wird von Ihrer Testsuite und Ihren Health Checks beansprucht und berührt nichts, was eine Nutzerin oder ein Nutzer sehen kann. Wenn Sie bereit sind, schalten Sie das Flag für ein Prozent des Traffics ein, beobachten Ihre Metriken und steigern dann auf zehn, fünfzig und hundert. Wenn etwas falsch aussieht, schalten Sie es in Sekunden wieder aus, ohne Deployment. Das Release wird zu einer Laufzeitentscheidung, die von einem Menschen getroffen wird, der Dashboards beobachtet, und nicht zu einem mechanischen Nebeneffekt eines Pushes.

Was Trunk-Based Development tatsächlich bedeutet

Trunk-Based Development ist ein Branching-Modell, bei dem alle mindestens einmal am Tag auf einen einzigen gemeinsamen Branch committen, den Trunk. Branches leben, falls es sie überhaupt gibt, für Stunden und werden am selben Tag gemergt.

Es geht nicht darum, dogmatisch mit Branches umzugehen. Es geht darum, die Distanz zwischen der Arbeit einer beliebigen Entwicklerin oder eines Entwicklers und der gemeinsamen Hauptlinie so kurz wie möglich zu halten, denn in dieser Distanz häuft sich der Integrationsschmerz an.

Stellen Sie dem langlebige Feature-Branches gegenüber. Ein Branch, der zwei Wochen überlebt, driftet still vom Trunk weg. Bis Sie ihn mergen, gleichen Sie die aufgelaufene Divergenz des gesamten Teams ab, und je größer der Merge, desto höher die Wahrscheinlichkeit, dass etwas bricht. Trunk-Based Development weigert sich, diese Schuld anwachsen zu lassen. Sie integrieren klein, Sie integrieren oft, und jede Integration ist langweilig.

Der offensichtliche Einwand lautet: Wie merge ich Code für eine Funktion, die erst halb fertig ist, ohne die Produktion zu brechen? Genau diese Lücke füllen Feature Flags.

Wo Feature Flags hineinpassen

Ein Feature Flag ist eine Bedingung in Ihrem Code, die zur Laufzeit entscheidet, ob ein Stück Verhalten aktiv ist. Im einfachsten Fall ist es eine Zeile: Wenn das Flag eingeschaltet ist, führe den neuen Pfad aus, andernfalls den alten. Diese winzige Indirektion ist es, die es Ihnen erlaubt, unfertige Arbeit sicher in den Trunk zu mergen, denn der neue Pfad bleibt dunkel, bis Sie sich entscheiden, ihn zu erleuchten.

Nicht alle Flags sind gleich, und sie als eine einzige Sache zu behandeln ist ein häufiger Fehler. Sie haben unterschiedliche Lebensdauern und unterschiedliche Verantwortliche.

Die vier Arten von Flags

• Release-Flags verbergen laufende Arbeit, damit sie gemergt werden kann, bevor sie fertig ist. Sie sind konzeptionell kurzlebig und sollten in dem Moment gelöscht werden, in dem eine Funktion vollständig ausgerollt ist. Dies ist das Flag, das Trunk-Based Development erst möglich macht.
• Operative Flags sind Notausschalter für riskante Teilsysteme: eine schwere Empfehlungs-Engine, eine wackelige Drittanbieter-Integration, eine neue Caching-Schicht. Sie sind absichtlich langlebig, denn Sie wollen die Möglichkeit haben, während eines Vorfalls Last abzuwerfen oder eine Abhängigkeit zu deaktivieren, ohne zu deployen.
• Experiment-Flags treiben A/B-Tests an. Sie leiten Nutzerkohorten zu verschiedenen Varianten und bleiben für die Dauer des Experiments bestehen und werden dann aufgeräumt, sobald ein Gewinner feststeht.
• Berechtigungs-Flags schalten Funktionen nach Plan, Rolle oder Konto frei, zum Beispiel einen Export nur für Unternehmen. Diese sind faktisch dauerhaft und gehören eher zu Ihrer Berechtigungslogik als zu Ihrer Auslieferungs-Pipeline.

Das Verwechseln dieser Kategorien ist der Punkt, an dem Flag-Systeme entgleisen. Ein Release-Flag, das wie ein Berechtigungs-Flag behandelt wird, wird nie gelöscht, und sechs Monate später erinnert sich niemand, ob es sicher zu entfernen ist.

Ein Workflow, der 2026 standhält

Hier ist ein konkreter Ablauf, den wir verwenden und Teams empfehlen, die auf Continuous Delivery umstellen. Er setzt eine solide Testsuite und einen echten Flagging-Dienst statt verstreuter Umgebungsvariablen voraus.

1. Zerteilen Sie die Arbeit in dünne vertikale Scheiben. Zerlegen Sie die Funktion in Stücke, die klein genug sind, um an einem Tag gemergt zu werden, jedes ein vollständiger Pfad durch den Stack, selbst wenn es zunächst nur interne Nutzer bedient.
2. Hüllen Sie den neuen Pfad in ein Release-Flag, standardmäßig ausgeschaltet. Der allererste Commit führt das Flag ein. Alles danach ändert Code, der in der Produktion bereits dunkel ist.
3. Mergen Sie täglich hinter dem Flag in den Trunk. Ihre Änderungen erreichen die Produktion kontinuierlich, beansprucht von CI und Integrationstests, aber unsichtbar für die Nutzer, weil das Flag ausgeschaltet ist.
4. Schalten Sie das Flag zuerst intern ein. Aktivieren Sie es für Ihr eigenes Team und Mitarbeiterkonten. Testen Sie das echte Produkt in der echten Umgebung, bevor eine Kundin oder ein Kunde es sieht.
5. Rollen Sie mit einem prozentualen Rollout hoch. Gehen Sie auf ein Prozent des Traffics, dann auf eine breitere Kohorte, und beobachten Sie Fehlerraten, Latenz und die Geschäftsmetrik, die die Funktion bewegen soll.
6. Beobachten Sie bei jedem Schritt Leitplanken-Metriken. Koppeln Sie den Rollout an Alarme. Wenn Fehlerbudgets aufgezehrt werden oder eine Schlüsselmetrik zurückgeht, haben Sie ein Signal, zu pausieren oder zurückzurollen, bevor die meisten Nutzer betroffen sind.
7. Rollen Sie durch Umschalten zurück, nicht durch Deployen. Wenn etwas bricht, schalten Sie das Flag aus. Der Fix ist sofort und schuldfrei, und Sie debuggen in aller Ruhe, während der Code sicher im Trunk bleibt.
8. Ziehen Sie das Flag zurück, sobald vollständig ausgerollt. Nachdem eine Funktion bei hundert Prozent und stabil ist, löschen Sie das Flag und den toten Code-Zweig im selben Sprint. Dieser Schritt ist nicht optional.

An diesem letzten Schritt scheitern die meisten Teams, deshalb verdient er seine eigene Disziplin.

Flag-Hygiene: Flag-Schulden abtragen

Jedes Release-Flag ist eine kleine Schuld. Jedes fügt eine Verzweigung in Ihrem Code hinzu, einen Zustand, den Ihre Tests abdecken müssen, und eine Zeile kognitiver Last für die nächste Person, die die Datei liest. Eine Handvoll ist in Ordnung. Mehrere hundert veraltete Schalter sind eine zweite, unsichtbare Codebasis, die niemand versteht und die alle zu berühren fürchten.

Halten Sie die Schuld mit ein paar Gewohnheiten niedrig:

• Geben Sie jedem Release-Flag ein Ablaufdatum und eine verantwortliche Person zum Zeitpunkt der Erstellung. Ein Flag ohne Verantwortliche ist ein Flag, das niemand jemals entfernen wird.
• Verfolgen Sie das Alter der Flags und behandeln Sie alles, was sein Ablaufdatum überschritten hat, als Bug in Ihrem Backlog, nicht als wünschenswerte Aufräumarbeit.
• Löschen Sie den Code, nicht nur den Schalter. Wenn Sie ein Flag entfernen, löschen Sie den verlierenden Zweig, damit der gewinnende Pfad zum einzigen Pfad wird.
• Begrenzen Sie die Anzahl aktiver Release-Flags pro Dienst. Ein hartes Limit erzwingt das Aufräumen, bevor sich neue Arbeit anhäuft.
• Prüfen Sie Berechtigungs- und operative Flags separat, da diese lange leben sollen und nicht in das Aufräumen der Release-Flags hineingezogen werden sollten.

Nach unserer Erfahrung sind die Teams, die schnell bleiben, nicht diejenigen, die am schnellsten Flags hinzufügen. Es sind diejenigen, die sie genauso schnell entfernen.

Kompromisse und Fehlermodi

Dieses Modell ist nicht umsonst, und etwas anderes vorzugeben bereitet Teams darauf vor, sich die Finger zu verbrennen.

• Die Testkombinationen explodieren. Bei vielen Flags wächst die Anzahl möglicher Zustände schnell. Sie können nicht jede Kombination testen, also testen Sie die Pfade, die zählen: den aktuellen Produktionszustand und den Ein- und Aus-Wert jedes Flags isoliert.
• Die Flag-Auswertung muss schnell und ausfallsicher sein. Ihre App liest Flags auf dem kritischen Pfad, daher darf ein langsamer oder nicht verfügbarer Flag-Dienst nicht in der Lage sein, Anfragen lahmzulegen. Cachen Sie die Flag-Werte lokal und definieren Sie einen sinnvollen Standardwert für den Fall, dass der Dienst unerreichbar ist.
• Flags sind eine Sicherheitsfläche. Ein Berechtigungs-Flag, das eine bezahlte Funktion freischaltet, ist eine Zugriffskontrollentscheidung. Werten Sie es auf dem Server aus, vertrauen Sie niemals einem vom Client gesendeten Flag-Wert und protokollieren Sie Änderungen an sensiblen Flags.
• Trunk-Based Development verlangt echte Tests. Das ganze Modell ruht auf einem Trunk, der immer auslieferbar ist. Ohne schnelle, vertrauenswürdige automatisierte Tests und Continuous Integration verbreitet das tägliche Mergen in den Trunk Defekte nur schneller.

Das sind dieselben Disziplinen, die auftauchen, sobald Sie ein System für unabhängige Auslieferung zerlegen. Wenn Sie zudem abwägen, wie weit Sie Ihre Architektur aufteilen sollen, behandelt unser Leitfaden zum Weg vom Monolithen zu Microservices die organisatorischen Signale, die unabhängiges Deployment seinen Preis wert machen, und die Flag-Mechanik hier ist die Art und Weise, wie Sie diese Dienste sicher ausliefern, sobald Sie sie haben.

Flags reisen auch entlang Ihrer API-Grenzen, daher sind die Verträge, die Sie offenlegen, von Bedeutung. Wenn eine mit einem Flag versehene Änderung die Form einer Antwort oder das Verhalten eines Endpunkts verändert, bewahren Sie die Prinzipien aus unserem Beitrag über das Entwerfen von APIs, die Entwickler lieben davor, eine brechende Änderung hinter einem harmlos aussehenden Schalter auszuliefern.

Wie Innovation T helfen kann

Trunk-Based Development und Feature Flags sind weniger der Kauf eines Werkzeugs als vielmehr eine Veränderung in der Arbeitsweise eines Teams: kleine Merges, Continuous Integration, progressiver Rollout und kompromissloses Aufräumen. Dorthin zu gelangen bedeutet in der Regel, die Testsuite zu straffen, die Auslieferungs-Pipeline zu härten und einen Flagging-Ansatz zu wählen, der zu Ihrer Größenordnung passt, statt zum größten Namen am Markt.

Bei Innovation T ist genau das die Art von Engineering-Arbeit, die wir leisten. Wir helfen Teams, von langlebigen Branches und gefürchteten Releases zu einem ruhigen, kontinuierlichen Fluss zu wechseln: Wir richten Trunk-Based-Workflows ein, verdrahten Feature Flags in eine CI- und CD-Pipeline, definieren Playbooks für Rollout und Rollback und bauen die Flag-Hygiene auf, die die Codebasis ein Jahr später sauber hält. Entdecken Sie unsere Leistungen im Software- und Cloud-Engineering, oder nehmen Sie Kontakt auf, um darüber zu sprechen, wie Ihr Team heute ausliefert und wo die Reibung wirklich liegt.