feat(superadmin): migrate internal docs from docusaurus to guava kb

docs/superadmin-kb/de/09-releases-tests/01-releases.md

@@ -0,0 +1,47 @@
+---
+title: Releases & Deployments
+---
+
+Dieses Dokument beschreibt, wie Releases vorbereitet und durchgeführt werden und welche Tests aus Ops‑Sicht Pflicht sind.
+
+## 1. Vor dem Release
+
+- Changelog grob durchsehen (Feature‑/Bugfix‑Umfang verstehen).
+- Datenbank‑Migrations prüfen:
+  - Sind `up`/`down` sauber und idempotent?
+  - Gibt es lange laufende Migrations (Index‑Builds)?
+- Konfig‑Änderungen:
+  - Neue ENV‑Variablen in `dokploy`/Compose hinterlegt?
+  - Secrets über Secret‑Store / Dokploy‑UI konfiguriert?
+
+## 2. Pflicht‑Tests vor Prod‑Deploy
+
+- **PHPUnit**:
+  - `php artisan test` oder mindestens relevante Suites (z.B. „Checkout“, „Storage“).
+- **Frontend‑Build**:
+  - `npm run build` (bzw. CI‑Job).
+- **E2E‑Smoke‑Tests** (siehe `docs/testing/e2e.md`):
+  - Guest‑Flow: Event beitreten, Foto hochladen, Anzeige prüfen.
+  - Tenant‑Flow: Login, Event anlegen, Medienübersicht öffnen.
+
+## 3. Deployment‑Ablauf (Beispiel Dokploy)
+
+- Neues Image wird gebaut und getaggt (z.B. `fotospiel-app:2025-11-20`).
+- Dokploy‑Stack aktualisieren:
+  - App‑Container.
+  - Queue/Horizon‑Container.
+  - Docs‑Container (falls betroffen).
+- Nach dem Deploy:
+  - `php artisan migrate --force`.
+  - Queues prüfen (`horizon:status`, `queue:failed`).
+  - Schnelle Smoke‑Tests in Prod (nur lesende Aktionen oder Test‑Tenant).
+
+## 4. Rollback‑Strategie
+
+- Vor dem Deploy aktuellen Datenbank‑Snapshot sicherstellen.
+- Vorheriges Image‑Tag notieren.
+- Rollback:
+  - Dokploy/Compose auf vorheriges Image zurückdrehen.
+  - Falls Migrations rückwärtskompatibel: ggf. `migrate:rollback`.
+  - Incident‑Eintrag mit Ursache und Lessons Learned ergänzen.
+