|
|
|
|
@ -0,0 +1,119 @@
|
|
|
|
|
# Release-Checkliste (Staging und Produktion)
|
|
|
|
|
|
|
|
|
|
| | |
|
|
|
|
|
|---|---|
|
|
|
|
|
| Gilt für | jedes Release auf Staging/Produktion; **Go-live** (erster Release mit echten Nutzern) zusätzlich die Punkte mit „Go-live“ |
|
|
|
|
|
| Stand | 2026-11-03 |
|
|
|
|
|
| Quellen | `docs/specs/2-katalog-daten.md` (§ 4.2, § 8.1 Aufgabe D1), `docs/auth-konfiguration.md` (§ 3, § 5), `docs/katalog-pflege.md` (§ 1, § 2), ADR-0002, ADR-0003, Issue #46 |
|
|
|
|
|
| Bezug | Refs #2 (Katalog), Refs #1 (Auth), Refs #46 (SMTP-Timeouts), Refs #43 (CI-Runner) |
|
|
|
|
|
|
|
|
|
|
Diese Datei ist die zentrale Stelle. Die ausführliche Auth-Liste bleibt in `docs/auth-konfiguration.md` § 5; die Release-Blocker daraus stehen hier, damit nichts übersehen wird.
|
|
|
|
|
|
|
|
|
|
**Grundregeln (CLAUDE.md, Rolle devops):** Kein Tag, kein Deployment, kein Store-Upload ohne ausdrückliche Freigabe von Chris. Infrastruktur (Server, DNS, Reverse Proxy, Firewall) richtet Chris ein bzw. gibt sie frei; devops liefert Anleitung und Prüfschritte. Secrets nie in Logs, Tickets oder dieser Datei. In den Prüfbefehlen stehen Platzhalter in `<…>`; echte Werte stehen nicht im Repo.
|
|
|
|
|
|
|
|
|
|
**Wer:** `Chris` = Entscheidung, Freigabe, Eingriff in die Infrastruktur; `devops` = Prüfung und Dokumentation.
|
|
|
|
|
|
|
|
|
|
Ergebnis je Punkt mit Datum und Umgebung (Staging/Prod) im Release-PR oder als Kommentar zu #2 festhalten.
|
|
|
|
|
|
|
|
|
|
## 1. Vor jedem Release
|
|
|
|
|
|
|
|
|
|
| ☐ | Punkt | Wer | Prüfung |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| ☐ | `main` ist grün (Format, Analyse, Tests, Web-Build, pgTAP, `e2e`, Deno-Schritte) | devops | Forgejo Actions, letzter Lauf auf `main` |
|
|
|
|
|
| ☐ | Version in `app/pubspec.yaml` gesetzt (`x.y.z+build`), Changelog und Release Notes erstellt | devops, docs-writer | `.claude/commands/release.md` |
|
|
|
|
|
| ☐ | Migrationen auf Staging eingespielt und geprüft; Produktion erst nach Freigabe | Chris | Verfahren **offen**, siehe 8 |
|
|
|
|
|
| ☐ | Backups laufen und Restore ist getestet (ADR-0002, Pflichtbaustein) | Chris | Nachweis des letzten Restore-Tests, **offen**, siehe 8 |
|
|
|
|
|
|
|
|
|
|
## 2. Katalog und Startbestand (Spec #2, KAT-05)
|
|
|
|
|
|
|
|
|
|
Reihenfolge immer: Migrationen, `vocabulary.sql`, `startbestand.sql` (Runbook `docs/katalog-pflege.md` § 2.5).
|
|
|
|
|
|
|
|
|
|
| ☐ | Punkt | Wer | Prüfung |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| ☐ | **C0:** Vokabular (`supabase/catalog/vocabulary.csv`, Genres und Mechaniken) von Chris freigegeben oder korrigiert; `vocabulary.sql` ist aus der freigegebenen CSV erzeugt | Chris | Freigabe als Kommentar in #2 oder im PR; CI-Schritt „erzeugte Dateien aktuell“ grün |
|
|
|
|
|
| ☐ | Startbestand in `startbestand.csv` gepflegt (mindestens 180, Ziel ca. 200), `startbestand.sql` und `startbestand-keys.csv` erzeugt und committet (C1) | Chris | Ablauf Runbook § 2.4; CI grün |
|
|
|
|
|
| ☐ | Herkunft der Fakten (SB3) und der Kurztexte (SB4) bestätigt; **rechtliche Prüfung** vor dem Release | Chris | schriftliche Bestätigung in #2 |
|
|
|
|
|
| ☐ | Vokabular und Startbestand auf der Zielumgebung eingespielt (nur per Tunnel/VPN, siehe 4) | Chris | `psql "$DB_URL" -v ON_ERROR_STOP=1 --single-transaction -f supabase/catalog/vocabulary.sql -f supabase/catalog/startbestand.sql` |
|
|
|
|
|
| ☐ | **Seed-Verhalten:** Auf Staging/Prod nicht auf `supabase start`/`supabase db reset` für Seeds verlassen. Runbook § 2.7: Das Verhalten von `supabase start` (Seeds nur beim ersten Start einer leeren DB) ist **nicht geprüft**. Seeds ausdrücklich per `psql` (Zeile oben) einspielen und mit `checks.sql` bestätigen | Chris, devops | Zeile oben plus nächster Punkt |
|
|
|
|
|
| ☐ | **`checks.sql` (SB1):** mindestens 180 sichtbare Startbestandsspiele; SB2, SB4 und SB6 melden 0 Verstöße | Chris (Abnahme C1) | `psql "$DB_URL" -f supabase/catalog/checks.sql` oder Inhalt im Studio-SQL-Editor. Erwartung: Status `ok` bei SB1/SB2/SB4/SB6, SB1-Istwert >= 180. Lokal/CI ist SB1 nur Information; auf Produktion zählt der Wert |
|
|
|
|
|
| ☐ | Das lokale Beispielspiel aus `seed.sql` ist auf Produktion nicht vorhanden (reiner Sicherheitsnetz-Check; `checks.sql` zählt es nicht mit) | devops | `select count(*) from public.games where title = 'Beispielspiel';` erwartet 0 |
|
|
|
|
|
| ☐ | **Go-live:** danach ist `startbestand.sql` eingefroren und wird nicht mehr eingespielt (Korrekturen nur im Studio, Spec-F6) | Chris | Hinweis im Release-PR |
|
|
|
|
|
|
|
|
|
|
Issue #2 wird erst nach der Abnahme von `checks.sql` auf Produktion (C1) und nach Fertigstellung von #4 (KAT-02) geschlossen, und nur von Chris.
|
|
|
|
|
|
|
|
|
|
## 3. Auth, SMTP und Gateway (Spec #1, D1, Issue #46)
|
|
|
|
|
|
|
|
|
|
Vollständige Liste mit AUTH-CFG-Verweisen: `docs/auth-konfiguration.md` § 5; Gateway-Vorgaben § 3. Release-Blocker:
|
|
|
|
|
|
|
|
|
|
| ☐ | Punkt | Wer | Prüfung |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| ☐ | GoTrue-Image gepinnt auf `supabase/gotrue:v2.197.0` (oder bewusst aktualisiert, dann Spike-Punkte wiederholen); Env-Block aus Auth § 2 vollständig; `GOTRUE_PASSWORD_HIBP_ENABLED=false` | Chris, devops | Auth § 5, erste Punkte; Env-Werte prüfen, ohne Secrets zu posten |
|
|
|
|
|
| ☐ | `GOTRUE_SMS_AUTOCONFIRM=false` (die Self-Hosting-Vorlage setzt `true`): Enumerationsschutz | devops | Signup mit bereits bestätigter Adresse liefert 200 mit leeren `identities`, nicht 422 `user_already_exists` (AUTH-CFG-24) |
|
|
|
|
|
| ☐ | **Proxy vor GoTrue mit `GOTRUE_RATE_LIMIT_HEADER=X-Forwarded-For`** (AUTH-CFG-13): Proxy **überschreibt** den Header, GoTrue ist von außen nicht direkt erreichbar | Chris (Einrichtung), devops (Test) | 31 Fehllogins derselben IP gegen `https://<domain>/auth/v1/token?grant_type=password` mit einem Testkonto: Nr. 31 liefert 429 `over_request_rate_limit`. Zweiter Test mit gefälschtem Header `X-Forwarded-For: 203.0.113.7`: darf die Drosselung nicht umgehen. Direktzugriff auf den GoTrue-Port von außen muss scheitern |
|
|
|
|
|
| ☐ | **Gateway sperrt `POST /auth/v1/otp` und `POST /auth/v1/magiclink`** (AUTH-CFG-20; `/otp` legt sonst Konten an) | Chris (Einrichtung), devops (Test) | `curl -s -o /dev/null -w '%{http_code}\n' -X POST https://<domain>/auth/v1/otp -H 'Content-Type: application/json' -d '{}'`, ebenso für `/auth/v1/magiclink`: erwartet Ablehnung durch das Gateway (z. B. 403/404), keine GoTrue-Antwort |
|
|
|
|
|
| ☐ | **SPA-Rewrite:** `/auth/confirm` wird von der Web-App ausgeliefert (alle Pfade auf `index.html`) | Chris (Einrichtung), devops (Test) | `curl -s -o /dev/null -w '%{http_code}\n' 'https://<domain>/auth/confirm?token_hash=x&type=email'` erwartet 200 und HTML der App |
|
|
|
|
|
| ☐ | **Mailvorlagen-URL** erreichbar (GoTrue lädt Vorlagen per URL und fällt bei Fehlern **still** auf Englisch zurück, Risiko R5); URL im Health-Check | Chris, devops | URL aus dem Env-Block per `curl -I` vom Server aus. **Testmail de und en** (Bestätigung und Reset) auf Staging: Betreff und Text in der richtigen Sprache, Link `<Site-URL>/auth/confirm?token_hash=…` |
|
|
|
|
|
| ☐ | SMTP-Anbieter mit AVV und Absender-Domain entschieden und eingerichtet (AUTH-CFG-22, F7, bisher **vertagt**) | Chris | echter Versand auf Staging |
|
|
|
|
|
| ☐ | **Alarm auf SMTP-Fehler:** GoTrue-Logs mit `unexpected_failure`/HTTP 500 bei `/recover`, `/resend`, `/signup` lösen einen Alarm aus (die App zeigt bei SMTP-Ausfall bewusst die neutrale „Prüfe dein Postfach“-Seite, Nutzer merken nichts) | Chris (Einrichtung), devops (Test) | Alarm einmal auslösen (z. B. SMTP-Host auf Staging kurz falsch setzen) und Eingang bestätigen |
|
|
|
|
|
| ☐ | **#46 Timeouts und Monitoring:** Gateway-/Proxy-Timeout und GoTrue-SMTP-Timeout so gesetzt, dass bei hängendem SMTP ein 504 **mit Status** vor dem Client-Timeout kommt (Werte noch nicht festgelegt, Spike aus #46 offen); Monitoring umfasst zusätzlich **Gateway-5xx/504** für `/recover`, `/resend`, `/signup`, nicht nur `unexpected_failure`/500 | Chris, devops | Spike aus #46 auf Staging (`GOTRUE_SMTP_HOST=10.255.255.1`, nicht routbar): Status und Dauer für bekannte und unbekannte Adresse; Ergebnis in `docs/auth-konfiguration.md` eintragen. **Solange #46 offen ist, nicht abhakbar** |
|
|
|
|
|
| ☐ | `GOTRUE_RATE_LIMIT_EMAIL_SENT=30` und Monitoring auf 429 `over_email_send_rate_limit`; Mindestabstand 60 s (AUTH-CFG-08); Link-Gültigkeit 1 h (AUTH-CFG-07) | devops | Auth § 5 |
|
|
|
|
|
| ☐ | Nach Passwortänderung geht keine Benachrichtigungs-Mail aus (AUTH-CFG-19) | devops | Testkonto auf Staging, Postfach prüfen |
|
|
|
|
|
| ☐ | Rechtstexte-URLs und `TERMS_VERSION` final (R11); Bundle-/Application-ID final (R15) | Chris | vor dem Store-Release |
|
|
|
|
|
|
|
|
|
|
## 4. Zugang zu Studio, Datenbank, Pooler und `/pg/` (Spec #2 § 4.2, Risiko R1)
|
|
|
|
|
|
|
|
|
|
Studio läuft als Rolle `postgres` bzw. `supabase_admin` und **umgeht RLS**; im Self-Hosting gibt es in Studio keine Benutzerverwaltung. Wer Studio, 5432, den Pooler oder `/pg/` erreicht, kann alle Daten lesen und ändern. Gilt für **Staging und Produktion**.
|
|
|
|
|
|
|
|
|
|
| ☐ | Punkt | Wer | Prüfung |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| ☐ | Studio nicht öffentlich erreichbar, nur per SSH-Tunnel oder VPN | Chris (Einrichtung), devops (Prüfung) | Von einem Rechner **außerhalb** von Tunnel/VPN: `curl -s -o /dev/null -m 5 -w '%{http_code}\n' https://<studio-adresse>/` darf keine Studio-Seite liefern (Timeout, 403/404 oder Verbindungsfehler) |
|
|
|
|
|
| ☐ | Postgres-Port 5432 nicht öffentlich | Chris, devops | von außen: `nc -zv -w 5 <server-ip> 5432` schlägt fehl |
|
|
|
|
|
| ☐ | Pooler (Supavisor, Standard 6543) nicht öffentlich | Chris, devops | von außen: `nc -zv -w 5 <server-ip> 6543` schlägt fehl (tatsächlicher Port **offen**, siehe 8) |
|
|
|
|
|
| ☐ | Kong-Route `/pg/` (pg-meta) nicht öffentlich | Chris, devops | `curl -s -o /dev/null -w '%{http_code}\n' https://<domain>/pg/tables` erwartet 403/404, nicht 200 |
|
|
|
|
|
| ☐ | **Basic-Auth** des Gateways gesetzt (`DASHBOARD_USERNAME`/`DASHBOARD_PASSWORD`, starkes Passwort, Standardwerte der Vorlage ersetzt) als zweite Schicht | Chris | Dashboard (per Tunnel) ohne Zugangsdaten liefert 401. Passwort nie ins Repo oder in Logs |
|
|
|
|
|
| ☐ | **Studio-Rolle bestätigt:** im Studio-SQL-Editor `select current_user;` ausführen; Ergebnis `postgres` oder `supabase_admin` (die Admin-Funktionen akzeptieren genau diese beiden Rollen, Spec § 4.2) | Chris | Ergebnis im Release-PR oder in #2 festhalten; bei anderer Rolle melden und Spec § 4.2 anpassen |
|
|
|
|
|
| ☐ | Im Studio nie `set …` ohne `local`, immer in einer Transaktion (Runbook § 1) | Chris | Dauerregel, kein Prüfbefehl |
|
|
|
|
|
|
|
|
|
|
Eingriffe an Firewall, Reverse Proxy und DNS führt Chris aus; devops liefert nur Anleitung und die Außen-Tests oben.
|
|
|
|
|
|
|
|
|
|
## 5. CI-Runner (ADR-0003, Issue #43, manuelle Schritte)
|
|
|
|
|
|
|
|
|
|
ADR-0003 hat den Status „Vorgeschlagen“. Solange die Schritte offen sind, gilt `docker-host` als nicht für externe Beiträge geeignet; **vor dem ersten externen Beitrag, spätestens vor Release**, Schritt B umsetzen oder das Repo privat stellen. Issue #43 erst danach schließen.
|
|
|
|
|
|
|
|
|
|
| ☐ | Punkt (ADR-0003, Abschnitt) | Wer | Prüfung |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| ☐ | **A. Verhalten prüfen:** Test-Fork-PR mit manipulierter `ci.yml`: Lauf wartet auf Freigabe; zweiter Push läuft ohne erneute Freigabe; danach Testkonto und Fork löschen | Chris | Ergebnis in #43 notieren; startet der Lauf ohne Freigabe: Repo sofort privat stellen |
|
|
|
|
|
| ☐ | **B.1** Erreichbarkeit des dind aus `docker`-Jobs prüfen | Chris | `curl -s -m 3 http://<Default-Gateway>:2375/version` im Job (Gateway wie in `ci.yml`) |
|
|
|
|
|
| ☐ | **B.2** Runner in Wegwerf-VM bzw. separaten Host ohne Host-Mounts, ohne LAN-Zugriff, ohne persönliche Daten verlagern | Chris | Beschreibung des Setups in #43 |
|
|
|
|
|
| ☐ | **B.3** Notbremse (Runner stoppen) bekannt und einmal geprobt | Chris | Weg laut ADR **unverifiziert** |
|
|
|
|
|
| ☐ | **B.4 / C.1** Runner nur für dieses Repo registriert; Fork-PR-Läufe werden nicht freigegeben, solange nicht isoliert | Chris | Forgejo: Einstellungen, Actions, Runner |
|
|
|
|
|
| ☐ | **C.5** Runner-Token rotiert (Vorschlag: alle 3 Monate, sofort bei Verdacht) | Chris | Datum der letzten Rotation notieren |
|
|
|
|
|
|
|
|
|
|
## 6. Mobile Stores (nur bei Store-Release)
|
|
|
|
|
|
|
|
|
|
Android-AAB und iOS-Build: Upload nur nach ausdrücklicher Freigabe von Chris. iOS benötigt einen macOS-Runner oder lokalen Mac. Signierung und Zugänge liegen bei Chris (nicht im Repo). Details sind noch nicht festgelegt (siehe 8).
|
|
|
|
|
|
|
|
|
|
## 7. Nach dem Deployment
|
|
|
|
|
|
|
|
|
|
| ☐ | Punkt | Wer | Prüfung |
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
| ☐ | Smoke-Test Web: Start, Registrierung, Bestätigungs-Link, Anmeldung, Katalog zeigt Spiele | Chris | manuell auf der Zielumgebung |
|
|
|
|
|
| ☐ | Tag `v<version>` erst nach Freigabe; der Release-Workflow übernimmt | Chris | `.claude/commands/release.md`, Schritt 4 |
|
|
|
|
|
|
|
|
|
|
## 8. Offene Punkte für Chris (fehlende Angaben, nichts davon wurde erfunden)
|
|
|
|
|
|
|
|
|
|
1. Adressen von Staging und Produktion (Domain, Studio-Adresse, Server-IP) und der Zugangsweg (SSH-Tunnel oder VPN, welches).
|
|
|
|
|
2. Welcher Reverse Proxy sitzt vor Kong/GoTrue; wie wird `X-Forwarded-For` dort gesetzt; wo werden `/auth/v1/otp` und `/magiclink` gesperrt (Proxy oder Kong).
|
|
|
|
|
3. Port des Pooler im tatsächlichen Setup; ob `/pg/` über Kong erreichbar ist.
|
|
|
|
|
4. Logging und Alarmierung: welches Werkzeug soll SMTP-Fehler, Gateway-5xx/504 und 429 `over_email_send_rate_limit` melden.
|
|
|
|
|
5. SMTP-Anbieter und Absender-Domain (F7 vertagt); Hosting der Mailvorlagen (URL).
|
|
|
|
|
6. Konkrete Timeout-Werte (GoTrue-SMTP, Proxy, Client) und Ergebnis des Spikes aus #46.
|
|
|
|
|
7. Verfahren für Migrationen auf Staging/Prod, Backup-/Restore-Runbook und Nachweis des Restore-Tests (ADR-0002; ein Betriebs-Runbook in `docs/` existiert noch nicht).
|
|
|
|
|
8. Ob Staging und Produktion auf demselben Server laufen (ADR-0002: getrennt, sobald echte Nutzer da sind).
|
|
|
|
|
9. Wie `DB_URL` für `psql` gebildet wird (Tunnel, Rolle); nicht ins Repo.
|
|
|
|
|
10. Entscheidung über ADR-0003 (Status „Vorgeschlagen“, Maßnahmen A/B/C).
|
|
|
|
|
11. Store-Release: Signierung, Bundle-/Application-ID (R15), Rechtstexte (R11).
|
|
|
|
|
|
|
|
|
|
## 9. Nicht geprüft (Stand dieser Datei)
|
|
|
|
|
|
|
|
|
|
Reine Dokumentation, erstellt ohne Zugriff auf Staging/Prod. Die Prüfbefehle wurden **nicht** ausgeführt; erwartete Ergebnisse (z. B. 403/404 bei gesperrten Routen) sind aus den Quellen abgeleitet. Ebenfalls nicht geprüft: das Verhalten von `supabase start` mit Seeds (Runbook § 2.7), das Verhalten von GoTrue bei hängendem SMTP (#46) und die Aussagen aus ADR-0003 zu Runner und Forgejo (laut ADR teils unverifiziert).
|