NCA Social Media
Aktualisiert:
Autor:
Roland Golla
Grüne Schalttafel Feature Flags mit drei Kippschaltern, einer leuchtet

Feature Flags: Definition

Ein Feature Flag ist ein Schalter, der zur Laufzeit entscheidet, welcher Codepfad ausgeführt wird. Damit lässt sich neuer Code ausliefern, ohne ihn sofort für Nutzer zu aktivieren. Ausrollen und Freischalten werden zu zwei getrennten Entscheidungen.

Feature Toggle ist der gleichbedeutende Begriff, Pete Hodgson hat die Muster dazu ausführlich beschrieben. Für Legacy Migrationen ist der Schalter das wichtigste einzelne Werkzeug: Er macht jeden Schritt rückholbar, ohne dass ein Deployment nötig ist. Wer eine Route auf neuen Code umleitet, eine Berechnung ablöst oder ein Schema umstellt, braucht genau diese Möglichkeit, in Sekunden zurückzugehen. Ohne Flag bleibt bei einem Problem nur der Rollback der gesamten Anwendung.

Inhalt

Feature Flags mit NCA: Schnelle Hilfe vom Experten

Wir liefern seit über 20 Jahren PHP Anwendungen aus, ohne Stichtage und ohne Wartungsfenster. Der Stack aus Symfony und Sulu läuft auf eigenen Servern in Deutschland, die Pipelines über GitHub Actions und GitLab CI. Schalter gehören für uns zur normalen Ausstattung, nicht zum Sonderfall.

Teams begleiten wir im PHP Consulting und beim Refactoring Workshop. Damit ein Schalter überhaupt sicher ist, braucht es Tests: PHPUnit, Functional Tests und Cypress über die Oberfläche. Tote Pfade nach dem Aufräumen finden PHPStan und Class Leak, das Entfernen automatisiert Rector PHP.

Lass uns sprechen

Finde das passende Angebot für dein Projekt

Anfrage-Konfiguration

Starten Sie Ihre Anfrage

Projektart
Infos
Nachricht

Eliminierung technischer Schulden mit PHPStan, Rector PHP und PHPUnit. Über 20 Jahre Praxiserfahrung in skalierbaren Backends.

CORE EXPERTISE

Gesetzliche Konformität & Inklusion. Optimierung von Performance und Conversion durch radikal nutzerzentriertes, universelles Design.

BFSG COMPLIANT

Skalierbare KI-Systeme mit echtem Code Ownership. CI/CD, Backup-Strategien und Infrastruktur, die mit deinem Team wächst.

ENTERPRISE READY

Deployment ist nicht gleich Release

Ohne Flags fallen zwei Dinge zusammen, die nichts miteinander zu tun haben. Deployment heißt, dass Code auf dem Server liegt. Release heißt, dass Nutzer ihn erleben. Wer beides koppelt, macht jedes Deployment zu einem Ereignis mit Publikum.

Die Folge kennt jedes Team: Es wird selten ausgeliefert, dafür viel auf einmal. Geht etwas schief, ist unklar, welche der zwanzig Änderungen schuld war. Der Rollback nimmt alles zurück, auch das, was funktioniert hat.

Mit einem Flag wandert der Code unauffällig in die Produktion und bleibt dort inaktiv. Freigeschaltet wird später, für einen kleinen Teil der Nutzer, dann für mehr. Zeigt das Monitoring ein Problem, geht der Schalter zurück auf aus. Kein Deployment, kein Rollback, keine Nachtaktion.

Für Legacy Migrationen ist das der entscheidende Hebel. Eine umgestellte Berechnung, eine auf neuen Code geleitete Route oder ein geändertes Schema lassen sich damit in Sekunden zurücknehmen. Genau diese Möglichkeit macht den Unterschied zwischen einem kontrollierten Schritt und einem Sprung ins Ungewisse.

Vier Arten von Schaltern

Der häufigste Fehler im Umgang mit Flags ist, sie alle gleich zu behandeln. Ein Schalter, der in zwei Wochen verschwinden soll, braucht eine andere Umsetzung als einer, der dauerhaft Tarifstufen steuert. Pete Hodgson unterscheidet vier Kategorien nach Absicht und Lebensdauer.

Die vier Arten von Feature Flags

Art Zweck Lebensdauer
Release Toggle Unfertige Arbeit im Hauptzweig verbergen Tage bis Wochen, danach entfernen
Experiment Toggle Varianten gegeneinander messen Laufzeit des Versuchs
Ops Toggle Notschalter für teure oder wackelige Funktionen Monate bis dauerhaft
Permission Toggle Funktionen je nach Tarif oder Rolle freigeben Dauerhaft, gehört zur Fachlogik

Umsetzung in Symfony

Für den Einstieg braucht es kein externes Produkt. Ein Interface, eine Implementierung und ein Eintrag in der Konfiguration reichen völlig.

Code: 
          
interface FeatureToggles
{
    public function isEnabled(string $name, ?Context $context = null): bool;
}

Entscheidend ist, dass die Abfrage hinter diesem Interface liegt und nicht direkt auf einer Umgebungsvariable oder einem Datenbankfeld arbeitet. Nur so lässt sich die Quelle später wechseln, ohne hunderte Stellen anzufassen, und nur so ist der Schalter im Test einfach steuerbar.

Für Release Toggles genügt oft ein Parameter in der Konfiguration. Sobald ein Anteil des Verkehrs oder eine Nutzergruppe gesteuert werden soll, kommt Kontext ins Spiel und die Entscheidung wandert in eine Datenbank oder einen Cache. Wichtig ist, dass die Abfrage schnell bleibt, weil sie auf heißen Pfaden liegt.

Im Test wird das Interface durch eine feste Implementierung ersetzt. Jeder Pfad braucht Abdeckung, sowohl an als auch aus. Ein Schalter, dessen zweiter Zweig nie getestet wurde, ist keine Absicherung, sondern eine zweite Fehlerquelle.

Flags sind Inventar mit Kosten

Jeder Schalter verdoppelt lokal die Zahl der möglichen Zustände. Bei drei Flags im selben Ablauf gibt es acht Kombinationen, von denen die meisten nie jemand ausprobiert hat. Genau dort entstehen die Fehler, die im Test nicht auffallen.

Deshalb gilt: Release Toggles bekommen von Anfang an ein Ablaufdatum. Sobald die Funktion vollständig ausgerollt ist, verschwindet der Schalter samt dem alten Pfad. Ein Ticket dafür entsteht zusammen mit dem Flag, nicht danach.

Praktisch bewährt haben sich drei Regeln. Erstens eine Liste aller aktiven Flags mit Verantwortlichem und geplantem Entfernungsdatum. Zweitens eine Prüfung im CI, die anschlägt, wenn ein Release Toggle sein Datum überschreitet. Drittens der Rückbau als eigener Merge Request, damit er reviewt wird statt nebenbei zu passieren.

Beim Aufräumen hilft Rector. Eine Regel entfernt die Bedingung und behält den gewünschten Zweig, über die gesamte Codebasis hinweg. Das ist zuverlässiger als Handarbeit, bei der schnell ein Zweig übrig bleibt, den niemand mehr erreicht.

Feature toggles are a powerful technique, allowing teams to modify system behaviour without changing code

Pete Hodgson, Consultant bei Thoughtworks – Feature Toggles auf martinfowler.com

Die NCA Erfahrung mit kontrollierten Releases

Teams, die selten ausliefern, liefern nicht seltener Fehler aus, sondern nur größere. Der Weg zu kleinen Schritten führt über Schalter, Tests und ein Monitoring, das Probleme meldet, bevor der Support anruft.

Die Absicherung läuft über PHPUnit, Functional Tests und Cypress, wobei jeder Schaltzustand eigene Abdeckung braucht. Vor dem Commit prüft GrumPHP, im CI achtet Patch Coverage auf neue Zeilen. Tote Pfade nach dem Rückbau finden PHPStan, Class Leak und Unused Public, entfernt werden sie mit Rector PHP. Ausgerollt wird über PHP Deployer, Schemaänderungen laufen über Doctrine Migrations.

CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.

Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Häufige Fragen zu Feature Flags

Was Teams beschäftigt, wenn sie Schalter zum ersten Mal ernsthaft einsetzen.

Was ist ein Feature Flag 2026 kurz erklärt?

Ein Schalter, der zur Laufzeit entscheidet, welcher Codepfad ausgeführt wird. Damit landet neuer Code in der Produktion, ohne dass Nutzer ihn sofort erleben. Ausliefern und Freischalten werden zu getrennten Entscheidungen, und eine Änderung lässt sich ohne Deployment zurücknehmen.

Sind Feature Flags und Feature Toggles 2026 dasselbe?

Ja, die Begriffe werden synonym verwendet. Verbreitet sind außerdem Feature Switch und Release Toggle, wobei letzteres nur eine bestimmte Art bezeichnet. Die ausführlichste Systematik stammt von Pete Hodgson und unterscheidet Release, Experiment, Ops und Permission Toggles.

Brauche ich 2026 ein kommerzielles Tool dafür?

Für den Anfang nicht. Ein Interface, eine Konfigurationsquelle und ein Eintrag im Service Container reichen für Release Toggles völlig aus. Ein externes Werkzeug lohnt sich, wenn viele Schalter gleichzeitig laufen, Fachbereiche selbst schalten sollen oder Nutzergruppen fein gesteuert werden.

Wie viele Flags sind 2026 zu viele?

Es gibt keine feste Zahl, aber ein gutes Warnsignal: Wenn niemand mehr sagen kann, welche Schalter aktiv sind und wer sie verantwortet, ist die Grenze überschritten. Drei Flags im selben Ablauf ergeben bereits acht Kombinationen. Release Toggles sollten deshalb konsequent nach dem Ausrollen verschwinden.

Wie teste ich Code mit Feature Flags 2026 richtig?

Beide Zustände brauchen Abdeckung. Im Test wird das Schalter Interface durch eine feste Implementierung ersetzt, einmal für an und einmal für aus. Ein nie getesteter Zweig ist keine Absicherung, sondern eine zusätzliche Fehlerquelle, die genau dann auffällt, wenn der Schalter unter Druck umgelegt wird.

Warum ist die Abfrage über ein Interface wichtig?

Weil sich die Quelle der Entscheidung ändern wird. Am Anfang steht sie in der Konfiguration, später in einer Datenbank oder einem Cache. Liegt die Abfrage hinter einem Interface, wechselt man die Implementierung an einer Stelle. Ohne diese Abstraktion sind hunderte Aufrufstellen betroffen.

Wie helfen Flags bei einer Legacy Migration?

Sie machen jeden Schritt rückholbar. Eine auf neuen Code geleitete Route, eine abgelöste Berechnung oder ein umgestellter Lesezugriff lassen sich in Sekunden zurückdrehen, ohne Deployment. Genau das unterscheidet einen kontrollierten Migrationsschritt von einem Sprung, bei dem nur der komplette Rollback bleibt.

Wann entferne ich einen Release Toggle wieder?

Sobald die Funktion vollständig ausgerollt und stabil ist. Das Ticket dafür entsteht zusammen mit dem Flag, inklusive geplantem Datum. Bewährt hat sich eine Prüfung im CI, die anschlägt, wenn ein Release Toggle sein Ablaufdatum überschreitet, sonst bleibt der Rückbau liegen.

Kann Rector beim Aufräumen helfen?

Ja, und das ist einer der überzeugendsten Anwendungsfälle. Eine Regel entfernt die Bedingung und behält den gewünschten Zweig, einheitlich über die ganze Codebasis. Von Hand bleibt fast immer irgendwo ein Zweig übrig, den niemand mehr erreicht und der später Verwirrung stiftet.

Beeinflussen Flags die Performance?

Sie können, wenn die Abfrage auf einem heißen Pfad liegt und jedes Mal die Datenbank befragt. Deshalb wird die Konfiguration pro Request geladen und im Speicher gehalten. Bei einfachen Schaltern aus der Konfiguration ist der Aufwand vernachlässigbar, bei kontextabhängigen Entscheidungen lohnt sich ein Blick ins Profiling.

Wie hängen Flags mit Parallel Change zusammen?

In der Migrate Phase steuert ein Flag, ob die alte oder die neue Variante genutzt wird. Damit lässt sich die Umstellung aktivieren und im Problemfall sofort zurückdrehen. In der Contract Phase fällt beides weg, der alte Pfad und der Schalter, sonst sammeln sich tote Schalter an.

Wie unterstützt Never Code Alone hier konkret?

Wir richten die Schalterinfrastruktur ein, klären die Arten und Lebensdauern und bauen die Prüfungen, die den Rückbau erzwingen. Dazu gehören die Tests für beide Zustände. Am Anfang steht ein kostenloses Kennenlernen, danach schätzen wir den Aufwand und rechnen transparent nach Minuten ab.