Konfigurationsreview

Das Problem

Konfiguration ist der Punkt, an dem Entwicklung und Betrieb kollidieren. Hardcodierte API-URLs brechen beim Deployment nach Staging. Fehlende Umgebungsvariablen crashen die App beim Start ohne nuetzliche Fehlermeldung. Secrets, die in die Git-Historie committet wurden, persistieren fuer immer. Feature Flags ohne Bereinigung haeufen sich zu einem unwartbaren Labyrinth aus Bedingungen.

Der Prompt

Pruefe das Konfigurationsmanagement im folgenden Code. Handle als DevOps-Engineer, der auditiert, wie die Anwendung umgebungsspezifische Einstellungen handhabt.

DEPLOYMENT: [z.B. Vercel, Docker, AWS Lambda, Netlify]
UMGEBUNGEN: [z.B. Development, Staging, Production]

DATEIEN:
[.env.example, Config-Dateien und Code, der Env-Vars liest, einfuegen]

Bewerte in diesen Dimensionen:

1. **Secrets-Management**
   - Sind Secrets im Quellcode hardcodiert?
   - Sind .env-Dateien von Git ausgeschlossen (.gitignore)?
   - Existiert eine .env.example mit Platzhaltern?

2. **Validierung beim Start**
   - Werden benoetigte Env-Vars beim App-Start validiert (nicht erst bei Nutzung)?
   - Erzeugen fehlende Vars klare Fehlermeldungen mit dem Namen der fehlenden Variable?
   - Werden Env-Vars typisiert (als Number, Boolean, URL geparst)?

3. **Defaults & Fallbacks**
   - Haben nicht-sensible Einstellungen sinnvolle Defaults?
   - Werden gefaehrliche Defaults vermieden (DEBUG=true, CORS=*)?

4. **Umgebungstrennung**
   - Ist Konfiguration nach Umgebung getrennt (nicht if/else-Ketten im Code)?
   - Kann dasselbe Build-Artefakt in jeder Umgebung laufen (12-Factor)?

5. **Feature Flags**
   - Werden Feature Flags zentral verwaltet?
   - Haben Flags Ablaufdaten oder Bereinigungserinnerungen?
   - Sind veraltete Flags (aelter als 3 Monate) fuer Bereinigung identifiziert?

6. **Dokumentation**
   - Ist jede Env-Var dokumentiert (Zweck, Format, Beispiel, pflicht/optional)?

Fuer jedes Problem liefere:
- **Datei**: Wo das Problem ist
- **Schweregrad**: Sicherheitsrisiko / Startcrash / Verwirrung / Verbesserung
- **Problem**: Was schiefgeht
- **Fix**: Korrigierter Konfigurationscode

Beispielausgabe

## Konfigurationsreview: 5 Probleme gefunden

### Sicherheitsrisiko: API-Key im Quellcode
Datei: src/lib/analytics.ts:3
Code: `const API_KEY = 'sk_live_abc123def456'`
Fix: In Env-Var verschieben:
  const API_KEY = process.env.ANALYTICS_API_KEY;

### Startcrash: Stille fehlende Env-Var
Datei: src/db.ts:5
Code: `const url = process.env.DATABASE_URL` — undefined wenn nicht gesetzt.
Fix (beim Start validieren):
  import { z } from 'zod';
  const env = z.object({
    DATABASE_URL: z.string().url(),
    PORT: z.coerce.number().default(3000),
  }).parse(process.env);

Wann verwenden

Bei Setup neuer Projekte, beim Onboarding neuer Entwickler oder bei Vorbereitung auf Deployment in einer neuen Umgebung ausfuehren. Unverzichtbar vor Produktions-Deployments und nach Vorfaellen, die durch Fehlkonfiguration verursacht wurden.

Profi-Tipps

• Alle Konfigurations-Touchpoints einbeziehen — nicht nur .env-Dateien, sondern auch den Code, der sie liest.
• Config-Schema anfordern — “Generiere ein zod-Schema, das alle Umgebungsvariablen beim Start mit korrekten Typen und Defaults validiert.”
• Git-Historie pruefen — “Wurden Secrets committet und dann entfernt? Sie existieren weiterhin in der Git-Historie.”