xPulse Chat – Release Day & Staging Switch Protocol

Dieses Dokument beschreibt den vollständigen Ablauf eines Release Days: vom Ende der Test-Period über den Production-Release bis zum Aufsetzen der neuen Staging-Umgebung für den nächsten RC.

Übersicht

1
Test-Period Ende
2
      ↓
3
RC auf Production mergen & deployen
4
      ↓
5
Staging Teardown (inkl. Log-Löschung)  ← Versprechen an Tester
6
      ↓
7
Neuen RC branch vorbereiten
8
      ↓
9
Neues Staging aufsetzen
10
      ↓
11
Neue Feedback Survey rausschicken

1. Test-Period Ende

• Feedback-Formular schließen (Antworten sichern / exportieren)
• Tester per E-Mail / Kanal informieren: „Test-Period beendet, Release folgt"
• Offene Feedback-Issues sichten – was kommt in diesen Release, was in den nächsten?

2. Production Release

2.1 Branch mergen

1
git checkout main
2
git merge --no-ff release/vX.Y.Z
3
git tag vX.Y.Z
4
git push origin main --tags

2.2 Production deployen

1
make prod-down
2
git pull
3
make prod

2.3 Smoke Test

• https://chat.xpulse.one erreichbar
• Login funktioniert
• Pairing funktioniert
• Version-Pill zeigt vX.Y.Z

3. Staging Teardown

Datenschutz-Versprechen: Nach Ende jeder Test-Period werden alle Staging-Container, Volumes und Logs vollständig entfernt. Tester-Aktivität ist danach nicht mehr rekonstruierbar.

3.1 Makefile Target

1
make stage-teardown

Das Target erledigt automatisch (siehe Makefile):

1. Container stoppen und entfernen
2. Docker Volumes entfernen (-v)
3. Log-Dateien in var/log/stage/ löschen
4. Docker Images für diesen RC entfernen

3.2 Manuell verifizieren

1
# Keine Container mehr laufen
2
docker ps | grep stage
3
 
4
# Log-Verzeichnis leer
5
ls -la var/log/stage/
6
 
7
# Subdomain nicht mehr erreichbar
8
curl -I https://rc-X-Y-Z.stage.xpulse.one
9
# → sollte 404 / Connection refused liefern

• Alle Checks bestanden
• Teardown-Zeitpunkt notieren: ____________________

4. Neuen RC Branch vorbereiten

1
git checkout -b release/vA.B.C
2
# .env.stage anpassen:
3
# RC_VERSION=rc-A-B-C

• RC_VERSION in .env.stage aktualisiert
• CHANGELOG.md Eintrag für vA.B.C angelegt
• Version-Pill in index.html / sidebar aktualisiert
• Pull-to-Refresh aus v1.2.0 in v1.3.0 übernehmen (modules/pull-to-refresh.js)

5. Neues Staging aufsetzen

1
make stage

Smoke Test Staging

• https://rc-A-B-C.stage.xpulse.one erreichbar
• Login funktioniert
• Pairing funktioniert
• Version-Pill zeigt korrekten RC

6. Neue Feedback Survey

• Neue Survey unter https://rc-A-B-C.stage.xpulse.one/feedback/vA.B.C/ deployen
• Roadmap-Items für diese Version in der Survey sichtbar
• Survey-Link testen
• Tester per E-Mail / Kanal informieren:
  • Neue Version verfügbar
  • Link zur Staging-Umgebung
  • Link zur Feedback Survey
  • Geplante Test-Period Dauer

Makefile Referenz

Versions-Historie dieses Protokolls