aYOUne

Feature Flags

Feature-Flags sind der Grundbaustein für stufenweise Rollouts, Beta-Programme und A/B-Tests in aYOUne. Sie leben in der config.flags-Collection und werden überall in der Plattform via flagsService.isEnabled(flagId, ctx) ausgewertet.

Das Flag-Modell

Ein Flag ist mehr als ein boolean. Es enthält:

Feld Beschreibung
_id Stabiler Slug, z.B. marketing.newsletter-v2
name Anzeige-Name
description Beschreibung für andere Admins
enabled Master-Schalter
rules[] Per-Customer/-User-/-Role-Bedingungen
defaultValue Wenn keine Rule matched
expiresAt Optional: Auto-Disable Datum

Flag setzen (UI)

admin-v2 → Feature Flags → Detail → "Regel hinzufügen". Beispiel: nur User der "Beta-Tester"-Rolle sehen das neue Newsletter-UI:

rules:
  - condition:
      role: 64a1b2...   # ObjectId der Role
    value: true
  - condition: {}      # Catch-All
    value: false

Flag setzen (CLI)

ay flag enable marketing.newsletter-v2
ay flag disable marketing.newsletter-v2
ay flag set marketing.newsletter-v2 --rule '{"role":"<id>"}' --value true
ay flag list                # alle Flags
ay flag get marketing.newsletter-v2

Auswertungs-Reihenfolge

Bei flagsService.isEnabled(flagId, ctx) durchläuft die Plattform:

  1. Wenn flag.enabled === false → false
  2. Wenn flag.expiresAt < now → false
  3. Iteriert flag.rules[] in Reihenfolge — erste matchende Rule gewinnt
  4. Sonst flag.defaultValue

Das macht Reihenfolge wichtig: spezifische Rules (z.B. customerId) gehören vor generische (z.B. role).

Mobile-App- und Customer-UI-Flags

Seit Kapitel 1.65 gibt es zwei spezielle Flag-Klassen:

  • mobile-app.* — wirken in der PWA für Customer-Admins
  • customer-ui.* — wirken in der Consumer-App (= deine End-User-Site)

Beispiel:

ay flag enable mobile-app.dark-mode
ay flag enable customer-ui.checkout-v2 --rule '{"locale":"de"}'

Rollout-Strategien

Strategie Wie
Beta-Whitelist rules.role = "Beta-Tester"
Customer-Pilot rules.customerId = "<id>"
Prozent-Rollout rules.percentage = 25 (hash-basiert auf userId)
Datum-basiert rules.afterDate = "2026-05-01"
Kill-Switch enabled = false → sofortige Deaktivierung

Best Practices

  • Slug = Modul.Feature.Variante: crm.lead-scoring.v2, nicht new-feature-test.
  • description Pflicht: Was ist es, warum existiert es, wann darf es weg?
  • Lifecycle-Disziplin: Nach Vollroll-Out das Flag löschen — sonst sammelt sich tech debt. ay flag list --orphan zeigt Flags ohne Rules.
  • Auditierbar: Jeder Toggle landet im Audit-Trail.

Verbindungen

Flags werden auch auf Backend-Seite genutzt: subscribeToReseedSignal() lauscht auf core.reseedStates.<modul> (60s-Poll), um State-Seeders ohne Pod-Restart neu auszulösen.