Git-Konventionen

Wir verwenden Conventional Commits (feat:, fix:, chore:), die Changelogs automatisch generieren. Branches werden nach Tickets benannt: feat/ZENO-123-add-heatmaps.

Commit-Messages sollten imperativ sein ("Heatmaps hinzufügen" nicht "Heatmaps hinzugefügt") und erklären warum, nicht nur was. Der Diff zeigt, was sich geändert hat – Ihre Message sollte die Begründung erklären.

Pull Requests

Jede Änderung durchläuft Code-Review. PRs sollten klein, fokussiert und mit Kontext für Reviewer versehen sein. Wir streben nach Reviews innerhalb von 4 Stunden während der Arbeitszeiten.

PR-Anforderungen:

Alle Tests bestehen
Typprüfung erfolgreich
Mindestens eine Genehmigung
Keine ungelösten Kommentare

Gute PR-Beschreibungen umfassen: was sich geändert hat, warum es sich geändert hat, wie es getestet wird, und alle Risiken oder Nachfolgearbeiten.

CI/CD-Pipeline

Jeder Push löst unsere CI-Pipeline aus: Lint, Typprüfung, Test, Build. Merges auf main werden automatisch in Staging deployed. Produktions-Deployments erfordern explizite Genehmigung.

Die Pipeline läuft in unter 5 Minuten. Wenn es länger dauert, behandeln wir das als Bug. Schnelle Feedback-Schleifen halten Entwickler produktiv.

Umgebungsmanagement

Wir pflegen drei Umgebungen:

Entwicklung: Lokale Maschinen mit Wrangler für Workers und lokalem Supabase.
Staging: Produktionsähnliche Umgebung unter Staging-Subdomains. Für finales QA und Demo verwendet.
Produktion: Das Echte. Nach Staging-Verifizierung und expliziter Genehmigung deployed.

Datenbankmigrationen

Schema-Änderungen durchlaufen Supabase-Migrationen. Jede Migration muss mit einer entsprechenden Down-Migration umkehrbar sein. Wir testen Migrationen auf Staging mit produktionsähnlichen Daten, bevor wir sie auf die Produktion anwenden.

Release-Prozess

Wir releasen kontinuierlich. Features gehen live, sobald sie bereit sind, geschützt durch Feature-Flags. Wichtige Änderungen werden in unserem Changelog mit klaren Migrationsleitfäden angekündigt.

Feature-Flags ermöglichen es uns, Code zu deployen, ohne ihn für Nutzer zu aktivieren. Das bedeutet sicherere Releases, schrittweise Rollouts und einfache Rollbacks, wenn etwas schiefgeht.