1.7 KiB
1.7 KiB
title, sidebar_label
| title | sidebar_label |
|---|---|
| Releases & Deployments | 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/downsauber und idempotent? - Gibt es lange laufende Migrations (Index‑Builds)?
- Sind
- Konfig‑Änderungen:
- Neue ENV‑Variablen in
dokploy/Compose hinterlegt? - Secrets über Secret‑Store / Dokploy‑UI konfiguriert?
- Neue ENV‑Variablen in
2. Pflicht‑Tests vor Prod‑Deploy
- PHPUnit:
php artisan testoder 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.