[P1] Minimale Betriebsdiagnose und Beta-Smoke-Test dokumentieren #14

New Issue

2026-09-15T09:43:35Z

metalcircle-bot commented

2026-09-15 09:43:35 +00:00

Ziel

Ein Betreiber kann eine Beta-Instanz auf Verfügbarkeit und Kernfunktionen prüfen und häufige Fehler ohne direkten Entwicklerzugriff eingrenzen.

Hintergrund

Das Repository enthält funktionale Tests und Dokumentation zur lokalen Entwicklung. Die Compose-Konfiguration definiert jedoch keine DB-/Web-Healthchecks, und es gibt keinen klaren Beta-Smoke-Test oder nachvollziehbaren Monitoring-/Fehlerdiagnose-Ablauf.

Ist-Zustand

Web und DB werden mit Restart-Policy gestartet; Web wartet per einfacher depends_on-Abhängigkeit auf die DB. Ein eigenes Health-/Readiness-Ende, Infrastruktur-Monitoring oder dokumentierter Beta-Smoke-Test ist nicht nachgewiesen. Die FCM-E2E-Strecke ist lokal erfolgreich getestet und in der Wiki-Dokumentation festgehalten.

Anforderungen

Sichere Liveness-/Readiness-Prüfung für Web und Datenbank definieren, ohne Secrets oder interne Daten auszugeben.
Minimalen Betreiber-Smoke-Test für Login, Konzertansicht, Kommentar/Teilnahme, Push-Präferenz und Android Push-Tap dokumentieren.
Betriebslogs zur Diagnose nutzbar machen, dabei Tokens, Session-IDs, Passwörter, Nachrichteninhalte und Secret-Konfigurationen ausschließen.
Zuständigkeit und Eskalationsweg für Ausfall, volle Datenträger, fehlgeschlagene Migrationen und Push-Zustellung festhalten.
Kleine Beta-Größe berücksichtigen; kein umfangreiches Analytics-/Observability-System voraussetzen.

Akzeptanzkriterien

Health-/Readiness-Status erkennt nicht verfügbare DB und meldet keine sensitiven Details.
Dokumentierter Smoke-Test ist von einem Betreiber ohne Entwicklerwerkzeuge ausführbar.
Logs enthalten genügend Kontext für Fehlerdiagnose, aber keine Tokens, Credentials oder privaten Nachrichteninhalte.
Neustart, DB-Verbindungsfehler und fehlgeschlagene Migration haben dokumentierte Diagnose-/Wiederanlaufhinweise.
Smoke-Test wurde einmal auf einer freigegebenen Beta-Umgebung ausgeführt.

Test / Verifikation

Healthchecks und Smoke-Test automatisiert bzw. manuell auf isolierter Beta-Umgebung ausführen; kontrollierte DB-Unterbrechung nur in dieser Testumgebung prüfen.

Abhängigkeiten

Beta-Deployment-Issue; die Durchführung auf Cloud-/PreProd-Umgebung erfordert den separaten Betreiber-Workflow.

## Ziel Ein Betreiber kann eine Beta-Instanz auf Verfügbarkeit und Kernfunktionen prüfen und häufige Fehler ohne direkten Entwicklerzugriff eingrenzen. ## Hintergrund Das Repository enthält funktionale Tests und Dokumentation zur lokalen Entwicklung. Die Compose-Konfiguration definiert jedoch keine DB-/Web-Healthchecks, und es gibt keinen klaren Beta-Smoke-Test oder nachvollziehbaren Monitoring-/Fehlerdiagnose-Ablauf. ## Ist-Zustand Web und DB werden mit Restart-Policy gestartet; Web wartet per einfacher `depends_on`-Abhängigkeit auf die DB. Ein eigenes Health-/Readiness-Ende, Infrastruktur-Monitoring oder dokumentierter Beta-Smoke-Test ist nicht nachgewiesen. Die FCM-E2E-Strecke ist lokal erfolgreich getestet und in der Wiki-Dokumentation festgehalten. ## Anforderungen - Sichere Liveness-/Readiness-Prüfung für Web und Datenbank definieren, ohne Secrets oder interne Daten auszugeben. - Minimalen Betreiber-Smoke-Test für Login, Konzertansicht, Kommentar/Teilnahme, Push-Präferenz und Android Push-Tap dokumentieren. - Betriebslogs zur Diagnose nutzbar machen, dabei Tokens, Session-IDs, Passwörter, Nachrichteninhalte und Secret-Konfigurationen ausschließen. - Zuständigkeit und Eskalationsweg für Ausfall, volle Datenträger, fehlgeschlagene Migrationen und Push-Zustellung festhalten. - Kleine Beta-Größe berücksichtigen; kein umfangreiches Analytics-/Observability-System voraussetzen. ## Akzeptanzkriterien - [ ] Health-/Readiness-Status erkennt nicht verfügbare DB und meldet keine sensitiven Details. - [ ] Dokumentierter Smoke-Test ist von einem Betreiber ohne Entwicklerwerkzeuge ausführbar. - [ ] Logs enthalten genügend Kontext für Fehlerdiagnose, aber keine Tokens, Credentials oder privaten Nachrichteninhalte. - [ ] Neustart, DB-Verbindungsfehler und fehlgeschlagene Migration haben dokumentierte Diagnose-/Wiederanlaufhinweise. - [ ] Smoke-Test wurde einmal auf einer freigegebenen Beta-Umgebung ausgeführt. ## Test / Verifikation Healthchecks und Smoke-Test automatisiert bzw. manuell auf isolierter Beta-Umgebung ausführen; kontrollierte DB-Unterbrechung nur in dieser Testumgebung prüfen. ## Abhängigkeiten Beta-Deployment-Issue; die Durchführung auf Cloud-/PreProd-Umgebung erfordert den separaten Betreiber-Workflow.

kai added this to the MetalCircle 0.1 Beta milestone 2026-09-15 09:52:19 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: kai/pingu-concerts#14