Skip to main content

Feature-Flags nach dem Release bereinigen

Plane eine einmalige Devin-Session, um ein Feature-Flag und den dazugehörigen toten Code zu entfernen, sobald sich dein Release stabilisiert hat.
AuthorCognition
CategoryAutomations
FeaturesSchedules
1

Plane die Bereinigung, wenn du das Flag auslieferst

Du hast gerade einen neuen Checkout-Flow hinter enable_new_checkout ausgerollt. Er ist in Produktion aktiviert, aber du möchtest eine Woche Monitoring, bevor du den alten Code wirklich entfernst. Anstatt ein Ticket zu erstellen, das du später vergisst, plane jetzt sofort eine einmalige Devin-Session – solange der Kontext noch frisch ist.Öffne die Schedule-Erstellungsseite und setze den Typ auf One-time. Wähle ein Datum nach deinem Monitoring-Fenster (z. B. nächsten Freitag um 9 Uhr). Wähle einen Slack-Channel, damit dein Team benachrichtigt wird, wenn die Session läuft und der PR bereit ist. Füge dann deinen Prompt ein:
2

Mach den Prompt möglichst präzise

Feature-Flags verstecken sich an unerwarteten Stellen – Config-Dateien, Test-Fixtures, Kommentare, Umgebungsvariablen. Je mehr Kontext du in den Prompt packst, desto sauberer wird das Ergebnis. Nimm Folgendes auf:
  • Wie eure Flags funktionieren – wo sie definiert sind und wie sie geprüft werden (z. B. useFeatureFlag('name') in React, isEnabled('name') in Backend-Services)
  • Was unverändert bleiben soll – das Flag-Framework selbst vs. das konkrete Flag (z. B. „Ändere src/lib/featureFlags/ nicht – das ist das Framework“)
  • Wo der alte und der neue Code liegen – z. B. „Der alte Checkout liegt in src/pages/checkout/legacy/, der neue Flow in src/pages/checkout/v2/“
  • Bereinigungsumfang – Kommentare, Doku, .env-Dateien und CI-Configs, die auf das Flag verweisen, sollten ebenfalls bereinigt werden
Ein Prompt mit diesem Detaillierungsgrad ermöglicht es Devin, alle Referenzen in einem Durchgang nachzuvollziehen – kein nachträglicher Sweep nötig.
3

Überprüfe den PR, wenn er erstellt ist

Wenn die geplante Session ausgelöst wird, verfolgt Devin jede Verwendung des Flags in deiner gesamten Codebase, behält den aktivierten Codepfad bei, entfernt den deaktivierten Pfad und toten Code, bereinigt Tests und öffnet einen PR. Du erhältst eine E-Mail-Benachrichtigung, sobald er bereit ist.Ein typischer PR sieht so aus:
Removed feature flag: enable_new_checkout

- Deleted flag from src/config/featureFlags.ts (1 file)
- Removed 12 conditional branches across 7 files
- Deleted src/pages/checkout/legacy/ (4 files, 380 lines)
- Updated 3 test files — removed flag mocking, deleted old-path tests
- All 1,204 tests passing
Bevor du den PR mergst, prüfe sorgfältig, ob keine Business-Logik aus dem alten Pfad hätte erhalten bleiben müssen – Fehlerbehandlung, Analytics-Events oder Edge-Case-Fallbacks liegen manchmal in dem „disabled“-Branch.