ausliefern und starten

Was macht ausliefern und starten?

Übersicht

Mit Zuversicht ausliefern. Das Ziel ist nicht nur zu deployen – es geht darum, sicher zu deployen, mit aktivem Monitoring, einem einsatzbereiten Rollback-Plan und einem klaren Verständnis davon, wie Erfolg aussieht. Jeder Launch sollte reversibel, beobachtbar und inkrementell sein.

Wann verwenden

• Erstmaliges Bereitstellen einer Funktion in der Produktion
• Ausliefern einer signifikanten Änderung an Benutzer
• Migration von Daten oder Infrastruktur
• Öffnen einer Beta- oder Early-Access-Phase
• Jede Bereitstellung, die mit Risiken verbunden ist (das sind alle)

Die Pre-Launch-Checkliste

Code-Qualität

• Alle Tests bestehen (Unit-, Integrations-, E2E-Tests)
• Build erfolgreich ohne Warnungen
• Linting und Typprüfung bestanden
• Code-Review durchgeführt und genehmigt
• Keine TODO-Kommentare, die vor dem Launch behoben werden müssen
• Keine console.log-Debugging-Anweisungen im Produktionscode
• Fehlerbehandlung deckt erwartete Fehlermodi ab

Sicherheit

• Keine Geheimnisse im Code oder in der Versionskontrolle
• Das Ökosystem-Abhängigkeitsaudit (npm audit, pip-audit, cargo audit, ...) zeigt keine kritischen oder hohen Schwachstellen
• Eingabevalidierung auf allen benutzerseitigen Endpunkten
• Authentifizierung und Autorisierung eingerichtet
• Sicherheitsheader konfiguriert (CSP, HSTS, etc.)
• Rate-Limiting auf Authentifizierungsendpunkten
• CORS auf bestimmte Ursprünge konfiguriert (kein Wildcard)

Performance

• Core Web Vitals innerhalb der „Gut“-Schwellenwerte
• Keine N+1-Abfragen in kritischen Pfaden
• Bilder optimiert (Kompression, responsive Größen, Lazy Loading)
• Bundle-Größe innerhalb des Budgets
• Datenbankabfragen haben passende Indizes
• Caching für statische Assets und wiederholte Abfragen konfiguriert

Barrierefreiheit

• Tastaturnavigation funktioniert für alle interaktiven Elemente
• Screenreader kann Seiteninhalt und -struktur vermitteln
• Farbkontraste erfüllen WCAG 2.1 AA (4,5:1 für Text)
• Fokus-Management bei Modals und dynamischen Inhalten korrekt
• Fehlermeldungen sind beschreibend und mit Formularfeldern verknüpft
• Keine Barrierefreiheitswarnungen in axe-core oder Lighthouse

Infrastruktur

• Umgebungsvariablen in der Produktion gesetzt
• Datenbankmigrationen angewendet (oder bereit zum Anwenden)
• DNS und SSL konfiguriert
• CDN für statische Assets konfiguriert
• Logging und Fehlerberichterstattung konfiguriert
• Health-Check-Endpunkt existiert und antwortet

Dokumentation

• README mit neuen Setup-Anforderungen aktualisiert
• API-Dokumentation aktuell
• ADRs für alle Architekturentscheidungen geschrieben
• Changelog aktualisiert
• Benutzerdokumentation aktualisiert (falls zutreffend)

Feature-Flag-Strategie

Hinter Feature Flags ausliefern, um Deployment von Release zu entkoppeln:

// Feature-Flag-Prüfung
const flags = await getFeatureFlags(userId);

if (flags.taskSharing) {
  // Neue Funktion: Aufgaben teilen
  return <TaskSharingPanel task={task} />;
}

// Standard: bestehendes Verhalten
return null;

Feature-Flag-Lebenszyklus:

1. DEPLOY mit Flag AUS     → Code ist in Produktion, aber inaktiv
2. AKTIVIEREN für Team/Beta → Interne Tests in der Produktionsumgebung
3. SCHRITTWEISER ROLLOUT   → 5% → 25% → 50% → 100% der Benutzer
4. ÜBERWACHEN auf jeder Stufe → Fehlerraten, Performance, Benutzerfeedback beobachten
5. AUFRÄUMEN               → Flag und toten Codepfad nach vollständigem Rollout entfernen

Regeln:

• Jedes Feature Flag hat einen Besitzer und ein Ablaufdatum
• Flags innerhalb von 2 Wochen nach vollständigem Rollout aufräumen
• Feature Flags nicht verschachteln (erzeugt exponentielle Kombinationen)
• Beide Flag-Zustände (ein und aus) in CI testen

Gestaffelter Rollout

Die Rollout-Sequenz

1. DEPLOY auf Staging
   └── Vollständige Testsuite in der Staging-Umgebung
   └── Manueller Smoke-Test kritischer Abläufe

2. DEPLOY auf Produktion (Feature Flag AUS)
   └── Deployment erfolgreich überprüfen (Health Check)
   └── Fehlerüberwachung prüfen (keine neuen Fehler)

3. AKTIVIEREN für Team (Flag EIN für interne Benutzer)
   └── Team nutzt die Funktion in der Produktion
   └── 24-Stunden-Überwachungsfenster

4. CANARY-Rollout (Flag EIN für 5% der Benutzer)
   └── Fehlerraten, Latenz, Benutzerverhalten überwachen
   └── Metriken vergleichen: Canary vs. Baseline
   └── 24-48 Stunden Überwachungsfenster
   └── Nur vorrücken, wenn alle Schwellenwerte bestehen (siehe Tabelle unten)

5. SCHRITTWEISE Erhöhung (25% -> 50% -> 100%)
   └── Gleiche Überwachung bei jedem Schritt
   └── Möglichkeit, jederzeit auf den vorherigen Prozentsatz zurückzukehren

6. VOLLSTÄNDIGER Rollout (Flag EIN für alle Benutzer)
   └── 1 Woche überwachen
   └── Feature Flag aufräumen

Rollout-Entscheidungsschwellenwerte

Verwenden Sie diese Schwellenwerte, um bei jeder Stufe zu entscheiden, ob Sie vorrücken, anhalten oder zurückrollen:

Metrik	Vorrücken (grün)	Anhalten und untersuchen (gelb)	Zurückrollen (rot)
Fehlerrate	Innerhalb von 10% der Baseline	10-100% über Baseline	>2x Baseline
P95-Latenz	Innerhalb von 20% der Baseline	20-50% über Baseline	>50% über Baseline
Client-JS-Fehler	Keine neuen Fehlertypen	Neue Fehler bei <0,1% der Sitzungen	Neue Fehler bei >0,1% der Sitzungen
Geschäftsmetriken	Neutral oder positiv	Rückgang <5% (kann Rauschen sein)	Rückgang >5%

Wann zurückrollen

Sofort zurückrollen, wenn:

• Fehlerrate um mehr als das 2-fache der Baseline steigt
• P95-Latenz um mehr als 50% steigt
• Benutzergemeldete Probleme stark zunehmen
• Datenintegritätsprobleme erkannt werden
• Sicherheitslücke entdeckt wird

Monitoring und Beobachtbarkeit

Was überwachen

Anwendungsmetriken:
├── Fehlerrate (gesamt und nach Endpunkt)
├── Antwortzeit (p50, p95, p99)
├── Anfragevolumen
├── Aktive Benutzer
└── Wichtige Geschäftsmetriken (Konversion, Engagement)

Infrastrukturmetriken:
├── CPU- und Speicherauslastung
├── Datenbankverbindungspool-Nutzung
├── Festplattenspeicher
├── Netzwerklatenz
└── Warteschlangentiefe (falls zutreffend)

Client-Metriken:
├── Core Web Vitals (LCP, INP, CLS)
├── JavaScript-Fehler
├── API-Fehlerraten aus Client-Perspektive
└── Seitenladezeit

Fehlerberichterstattung

// Fehlergrenze mit Berichterstattung einrichten
class ErrorBoundary extends React.Component {
  componentDidCatch(error: Error, info: React.ErrorInfo) {
    // An Fehlerverfolgungsdienst melden
    reportError(error, {
      componentStack: info.componentStack,
      userId: getCurrentUser()?.id,
      page: window.location.pathname,
    });
  }

  render() {
    if (this.state.hasError) {
      return <ErrorFallback onRetry={() => this.setState({ hasError: false })} />;
    }
    return this.props.children;
  }
}

// Serverseitige Fehlerberichterstattung
app.use((err: Error, req: Request, res: Response, next: NextFunction) => {
  reportError(err, {
    method: req.method,
    url: req.url,
    userId: req.user?.id,
  });

  // Keine Interna an Benutzer weitergeben
  res.status(500).json({
    error: { code: 'INTERNAL_ERROR', message: 'Etwas ist schiefgelaufen' },
  });
});

Überprüfung nach dem Launch

In der ersten Stunde nach dem Launch:

1. Prüfen, ob der Health-Endpunkt 200 zurückgibt
2. Dashboard zur Fehlerüberwachung prüfen (keine neuen Fehlertypen)
3. Latenz-Dashboard prüfen (keine Regression)
4. Kritischen Benutzerablauf manuell testen
5. Überprüfen, ob Logs fließen und lesbar sind
6. Rollback-Mechanismus bestätigen (falls möglich als Trockentest)

Fehlerbudget-Release-Gate

Das Fehlerbudget Ihres Dienstes – der Anteil der Anfragen oder der Zeit, den Ihr SLO ausfallen lässt – bestimmt, ob eine Auslieferung sicher ist. Verwenden Sie es als objektives Tor – nicht als Verhandlungssache:

Verbleibendes Budget > 20%  →  Normal ausliefern; genau überwachen
Verbleibendes Budget 0–20%  →  Nur langsame Rollouts; keine risikoreichen Änderungen
Budget erschöpft            →  Feature-Arbeit einfrieren; vollständig auf Zuverlässigkeit konzentrieren
Budget setzt zurück         →  Normales Tempo wieder aufnehmen; die Behebung einbacken, die es wiederhergestellt hat

Eine hohe Verbrauchsrate während eines Canary (das Budget schneller verbrauchend als die Baseline) ist ein Anhalten-Signal in der Rollout-Entscheidungstabelle oben – behandeln Sie es wie eine erhöhte Fehlerrate.

Rollback-Strategie

Jede Bereitstellung benötigt einen Rollback-Plan, bevor sie stattfindet:

## Rollback-Plan für [Feature/Release]

### Auslösebedingungen
- Fehlerrate > 2x Baseline
- P95-Latenz > [X]ms
- Benutzermeldungen zu [spezifischem Problem]

### Rollback-Schritte
1. Feature Flag deaktivieren (falls zutreffend)
   ODER
1. Vorherige Version bereitstellen: `git revert <commit> && git push`
2. Rollback überprüfen: Health Check, Fehlerüberwachung
3. Kommunizieren: Team über Rollback informieren

### Datenbankaspekte
- Migration [X] hat ein Rollback: `npx prisma migrate rollback`
- Daten, die durch die neue Funktion eingefügt wurden: [erhalten / bereinigt]

### Zeit bis zum Rollback
- Feature Flag: < 1 Minute
- Erneutes Bereitstellen der vorherigen Version: < 5 Minuten
- Datenbank-Rollback: < 15 Minuten

Siehe auch

• Für die projektweite Definition of Done, die jede Änderung vor dieser Checkliste bestehen muss, siehe ../../references/definition-of-done.md
• Für Sicherheitschecks vor dem Launch, siehe ../../references/security-checklist.md
• Für die Performance-Checkliste vor dem Launch, siehe ../../references/performance-checklist.md
• Für die Überprüfung der Barrierefreiheit vor dem Launch, siehe ../../references/accessibility-checklist.md
• Für die Alerting-Regeln und SLO-gebundenen Schwellenwerte, siehe observability-and-instrumentation

Häufige Rechtfertigungen

Rechtfertigung	Realität
„Es funktioniert auf Staging, also wird es auch in der Produktion funktionieren“	Produktion hat andere Daten, Traffic-Muster und Randfälle. Nach dem Deployen überwachen.
„Wir brauchen dafür keine Feature Flags“	Jede Funktion profitiert von einem Kill-Switch. Selbst „einfache“ Änderungen können Dinge kaputt machen.
„Monitoring ist Overhead“	Ohne Monitoring entdecken Sie Probleme durch Benutzerbeschwerden statt durch Dashboards.
„Wir fügen Monitoring später hinzu“	Fügen Sie es vor dem Launch hinzu. Sie können nichts debuggen, was Sie nicht sehen können.
„Ein Rollback ist ein Eingeständnis des Scheiterns“	Ein Rollback ist verantwortungsvolles Engineering. Eine kaputte Funktion auszuliefern, ist das Scheitern.
„Die Fehlerrate sieht gut aus, lassen Sie uns weiter ausliefern“	Überprüfen Sie die Verbrauchsrate, nicht nur die aktuelle Fehlerrate. Wenn das Budget schneller verbraucht wird als die Baseline, ist das ein Anhalten-Signal, selbst wenn einzelne Schwellenwerte grün sind.

Rote Flaggen

• Ausliefern ohne Rollback-Plan
• Kein Monitoring oder keine Fehlerberichterstattung in der Produktion
• Big-Bang-Releases (alles auf einmal, kein Staging)
• Feature Flags ohne Ablaufdatum oder Besitzer
• Niemand überwacht das Deployment in der ersten Stunde
• Produktionsumgebungs-Konfiguration aus dem Gedächtnis, nicht aus Code
• „Es ist Freitagnachmittag, lassen Sie es uns ausliefern“
• Fehlerbudget erschöpft, aber Feature-Arbeit wird unverändert fortgesetzt

Überprüfung

Vor dem Bereitstellen:

• Pre-Launch-Checkliste abgeschlossen (alle Abschnitte grün)
• Feature Flag konfiguriert (falls zutreffend)
• Rollback-Plan dokumentiert
• Monitoring-Dashboards eingerichtet
• Team über Deployment informiert

Nach dem Bereitstellen:

• Health Check gibt 200 zurück
• Fehlerrate ist normal
• Latenz ist normal
• Kritischer Benutzerablauf funktioniert
• Logs fließen
• Rollback getestet oder als bereit verifiziert

Für jeden ausgelieferten Dienst:

• Fehlerbudget-Richtlinie vorhanden: wissen, welche Maßnahmen ergriffen werden, wenn das Budget unter 20% fällt und wenn es erschöpft ist