Feature Flag

Ein Feature Flag (oder Feature Toggle) ist eine Bedingung im Code, deren Wert zur Laufzeit aus der Konfiguration kommt: Ist das Flag für diesen Nutzer oder diese Umgebung aktiv, wird der neue Pfad genommen, sonst der alte. Es trennt das Deployen von Code vom Releasen eines Features. Code kann ausgeschaltet in Produktion liegen, dann für interne Nutzer aktiviert werden, dann für 10 % der Kunden, dann für alle – und in Sekunden wieder abgeschaltet werden, wenn etwas schiefgeht.

Beispiel

if (flags.isEnabled('new-checkout', { userId: user.id })) {
  return renderNewCheckout(cart);
}
return renderLegacyCheckout(cart);

Der Flag-Service (ein kommerzielles Produkt, eine Open-Source-Lösung oder eine Tabelle in Ihrer eigenen Datenbank) bestimmt den Wert pro Nutzer, oft nach Prozentsatz oder Attribut.

Was das für das Testen bedeutet

Jedes Flag verdoppelt die Zahl möglicher Pfade durch dieses Stück Code. Ein Tester muss wissen:

• Welche Flag-Zustände gemeinsam ausgeliefert werden. Testen Sie die Kombination, die tatsächlich in Produktion live sein wird, nicht nur „alles an“.
• Beide Seiten jedes aktiven Flags. Der alte Pfad ist Produktionscode, bis das Flag entfernt wird, also müssen Regressionssuites ihn abdecken.
• Das Umschalten selbst. Das Flag während einer Session ein- oder auszuschalten, darf keine Daten beschädigen und keinen Nutzer mitten in einem Ablauf hängen lassen.
• Kontrolle in Tests. Automatisierte Tests sollten Flag-Werte explizit setzen, etwa über eine reine Test-API, ein Cookie oder einen Config-Override, statt von dem abzuhängen, was die geteilte Umgebung gerade eingestellt hat. Sonst bricht jemand, der ein Flag umlegt, unbeteiligte Testläufe – und das sieht genau wie Flakiness aus.

test('new checkout shows delivery slots', async ({ page, context }) => {
  await context.addCookies([
    { name: 'ff_new-checkout', value: 'on', url: 'https://staging.example.com' },
  ]);
  await page.goto('https://staging.example.com/checkout');
  await expect(page.getByRole('heading', { name: 'Choose a delivery slot' })).toBeVisible();
});

Der Cookie-Name dient hier nur der Veranschaulichung; verwenden Sie den Override-Mechanismus, den Ihr Flag-System bietet.

Häufige Fehler

Flags, die nie entfernt werden, sind die größten langfristigen Kosten: tote Zweige, Kombinationen, die niemand versteht, und alte Pfade, die unbemerkt verrotten. Behandeln Sie jedes Release-Flag als temporär, mit einem Owner und einem Entfernungsdatum, und löschen Sie den unterlegenen Zweig samt seinen Tests, sobald der Rollout abgeschlossen ist.