kai/pingu-concerts
1
0
Fork 0
Code Issues 10 Pull Requests Actions Packages Projects Releases Wiki Activity

[P0] Isolierte Beta-Umgebung mit sicherem Release- und Rollback-Weg festlegen #15

New Issue
Open
opened 2026-09-15 09:50:29 +00:00 by metalcircle-bot · 0 comments
metalcircle-bot commented 2026-09-15 09:50:29 +00:00
Copy Link
Copy Source

Ziel

Einen reproduzierbaren, abgesicherten Weg schaffen, MetalCircle 0.1 Beta in einer eigenen HTTPS-Umgebung bereitzustellen und bei einem fehlerhaften Upgrade zurückzugehen.

Hintergrund

Das Repository enthält aktuell primär eine lokale Compose-Konfiguration. Sie veröffentlicht den Web-Port direkt, startet Web und Datenbank ohne Health-Checks und dokumentiert keine ausführbare Beta-/Produktions-Release-Prozedur. Für lokale Entwicklung und Cloud-/PreProd gelten ausdrücklich getrennte Verantwortlichkeiten; diese Trennung muss auch im Release-Artefakt erhalten bleiben.

Ist-Zustand

Compose persistiert PostgreSQL sowie öffentliche und private Uploads in Volumes. COOKIE_SECURE ist in Compose standardmäßig true; der App-Default ist dagegen false. Das Android-Frontend hat eine fest konfigurierte Standard-Server-URL. Die Wiki-Seite beschreibt die Umgebungen und verbietet automatischen Zugriff, enthält aber keinen verifizierten Beta-Deployment-/Rollback-Ablauf. Dieses Issue ändert keine laufende Umgebung; Umsetzung und Probe erfolgen kontrolliert auf einer eigens freigegebenen Beta-Umgebung.

Anforderungen

  • Beta- und Produktionskonfiguration eindeutig von lokalem Testbetrieb trennen; keine Test-Secrets, Firebase-Service-Accounts oder Gitea-Testtokens in Beta/Produktion wiederverwenden.
  • Öffentlichen Zugriff ausschließlich über festgelegte Domain und HTTPS-Reverse-Proxy bereitstellen; Backend-/DB-Ports nicht direkt öffentlich exponieren, sichere Cookies und vertrauenswürdige Proxy-Header sicherstellen.
  • Persistenz von DB, Flyern, Profil-/Veranstaltungsbildern und privaten Uploads dokumentieren und verifizieren.
  • Geordnete Migrationen, Web-Neustart, Health-Checks und einen nachvollziehbaren Rollback-Schritt beschreiben.
  • Android-Buildziel und Beta-URL ausdrücklich auf die Beta-Umgebung richten; keine unbeabsichtigte Nutzung der Produktions-URL.
  • Secrets zur Laufzeit aus der freigegebenen Secret-Verwaltung laden; keine Werte ins Repository schreiben.

Akzeptanzkriterien

  • Eine dokumentierte, reproduzierbare Beta-Konfiguration ist ohne lokale .env-Werte lauffähig.
  • HTTPS, Secure-Cookies, Reverse-Proxy-Weitergabe und externe Portfreigaben sind mit einem Smoke-Test geprüft.
  • DB und alle Upload-Arten bleiben nach Container-Neustart vorhanden.
  • Migration auf leerer DB und Upgrade einer Kopie des vorgesehenen Vor-Beta-Schemas sind erfolgreich.
  • Fehlerhaftes App-Upgrade kann nach dokumentiertem Verfahren zurückgerollt werden.
  • Beta-APK/AAB zeigt auf Beta, nicht auf Localhost oder eine unbeabsichtigte Umgebung.
  • Keine Produktions-/PreProd-Systeme oder Secrets werden im Entwicklungsworkflow automatisch berührt.

Test / Verifikation

Auf einer eigens freigegebenen Beta-Umgebung Deploy-/Upgrade-/Restart-/Rollback-Probe und Smoke-Test durchführen; öffentliche Erreichbarkeit, TLS, Cookies, Datenpersistenz und Logs prüfen.

Abhängigkeiten

Android-Release-Artefakt und Backup-/Restore-Verfahren separat berücksichtigen. Cloud-/PreProd-Zugriffe erfolgen nur im dafür autorisierten Betreiber-Workflow.

## Ziel Einen reproduzierbaren, abgesicherten Weg schaffen, MetalCircle 0.1 Beta in einer eigenen HTTPS-Umgebung bereitzustellen und bei einem fehlerhaften Upgrade zurückzugehen. ## Hintergrund Das Repository enthält aktuell primär eine lokale Compose-Konfiguration. Sie veröffentlicht den Web-Port direkt, startet Web und Datenbank ohne Health-Checks und dokumentiert keine ausführbare Beta-/Produktions-Release-Prozedur. Für lokale Entwicklung und Cloud-/PreProd gelten ausdrücklich getrennte Verantwortlichkeiten; diese Trennung muss auch im Release-Artefakt erhalten bleiben. ## Ist-Zustand Compose persistiert PostgreSQL sowie öffentliche und private Uploads in Volumes. `COOKIE_SECURE` ist in Compose standardmäßig `true`; der App-Default ist dagegen `false`. Das Android-Frontend hat eine fest konfigurierte Standard-Server-URL. Die Wiki-Seite beschreibt die Umgebungen und verbietet automatischen Zugriff, enthält aber keinen verifizierten Beta-Deployment-/Rollback-Ablauf. Dieses Issue ändert keine laufende Umgebung; Umsetzung und Probe erfolgen kontrolliert auf einer eigens freigegebenen Beta-Umgebung. ## Anforderungen - Beta- und Produktionskonfiguration eindeutig von lokalem Testbetrieb trennen; keine Test-Secrets, Firebase-Service-Accounts oder Gitea-Testtokens in Beta/Produktion wiederverwenden. - Öffentlichen Zugriff ausschließlich über festgelegte Domain und HTTPS-Reverse-Proxy bereitstellen; Backend-/DB-Ports nicht direkt öffentlich exponieren, sichere Cookies und vertrauenswürdige Proxy-Header sicherstellen. - Persistenz von DB, Flyern, Profil-/Veranstaltungsbildern und privaten Uploads dokumentieren und verifizieren. - Geordnete Migrationen, Web-Neustart, Health-Checks und einen nachvollziehbaren Rollback-Schritt beschreiben. - Android-Buildziel und Beta-URL ausdrücklich auf die Beta-Umgebung richten; keine unbeabsichtigte Nutzung der Produktions-URL. - Secrets zur Laufzeit aus der freigegebenen Secret-Verwaltung laden; keine Werte ins Repository schreiben. ## Akzeptanzkriterien - [ ] Eine dokumentierte, reproduzierbare Beta-Konfiguration ist ohne lokale `.env`-Werte lauffähig. - [ ] HTTPS, Secure-Cookies, Reverse-Proxy-Weitergabe und externe Portfreigaben sind mit einem Smoke-Test geprüft. - [ ] DB und alle Upload-Arten bleiben nach Container-Neustart vorhanden. - [ ] Migration auf leerer DB und Upgrade einer Kopie des vorgesehenen Vor-Beta-Schemas sind erfolgreich. - [ ] Fehlerhaftes App-Upgrade kann nach dokumentiertem Verfahren zurückgerollt werden. - [ ] Beta-APK/AAB zeigt auf Beta, nicht auf Localhost oder eine unbeabsichtigte Umgebung. - [ ] Keine Produktions-/PreProd-Systeme oder Secrets werden im Entwicklungsworkflow automatisch berührt. ## Test / Verifikation Auf einer eigens freigegebenen Beta-Umgebung Deploy-/Upgrade-/Restart-/Rollback-Probe und Smoke-Test durchführen; öffentliche Erreichbarkeit, TLS, Cookies, Datenpersistenz und Logs prüfen. ## Abhängigkeiten Android-Release-Artefakt und Backup-/Restore-Verfahren separat berücksichtigen. Cloud-/PreProd-Zugriffe erfolgen nur im dafür autorisierten 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.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
android
Betrifft die MetalCircle-Android-App oder die Capacitor-/Android-Integration.
 backend
Betrifft FastAPI, serverseitige Logik, Datenbank oder interne APIs.
 bug
Fehler oder unerwartetes Verhalten, das behoben werden muss.
 database
Betrifft PostgreSQL, Datenmodell, Migrationen oder Datenintegrität.
 deployment
Betrifft Docker, Staging, Production, Deployment oder Infrastruktur.
 enhancement
Verbesserung oder neue Funktion, kein bestehender Fehler.
 frontend
Betrifft Benutzeroberfläche, Templates, JavaScript, Styling oder Interaktionen.
 push
Betrifft Firebase Cloud Messaging, Push-Registrierung oder Benachrichtigungen.
 reported-from-metalcircle
Automatisch über den integrierten MetalCircle-Bugreporter erstellt.
 security
Sicherheitsrelevantes Problem oder notwendige Härtungsmaßnahme.
 web
Betrifft die Web-Version von MetalCircle oder browserspezifisches Verhalten.
No Label
Milestone
No items
No Milestone MetalCircle 0.1 Beta
Projects
Clear projects
No project
Assignees
Clear assignees
codex-bot (MetalCircle Codex Bot) kai
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kai/pingu-concerts#15
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?