Updates einspielen

Ein Update besteht immer aus zwei Teilen: neue Container-Images und — falls sich das Datenmodell geändert hat — Datenbankmigrationen. Beides erledigt das mitgelieferte Deploy-Skript in der richtigen Reihenfolge.

Grundprinzip

Images werden nicht auf dem Server gebaut. Sie werden aus der Container-Registry geladen, in der Version, die in der Datei deployment/.env unter IMAGE_TAG steht. Ein Update ist damit immer: neuen Tag eintragen → Deploy-Skript ausführen.

Ablauf

cd deployment

# 1. Zielversion eintragen (Beispiel)
#    IMAGE_TAG=0.1.0-alpha.16
nano .env

# 2. Deploy
bash scripts/deploy.sh

Das Skript führt aus:

Schritt	Was passiert
1	Voraussetzungen prüfen — Docker, Compose, Konfiguration vorhanden
2	Datenbank-Schnappschuss — vollständiger Dump vor jeder Änderung
3	Images laden — docker compose pull mit dem neuen IMAGE_TAG
4	Migrationen — alembic upgrade head. Schlägt eine Migration fehl, bricht das Skript ab und die laufende Version bleibt unangetastet.
5	Container ersetzen — docker compose up -d
6	Health-Check — wartet, bis der Health-Endpunkt wieder antwortet

Die Anwendung ist dabei kurz nicht erreichbar (typisch 10–30 Sekunden), während die Container ersetzt werden. Für unterbrechungsfreie Updates wären mehrere Instanzen hinter einem Load Balancer nötig — das ist nicht Teil des Lieferumfangs.

Nach dem Update prüfen

# Health-Endpunkt
curl -s https://<deine-domain>/api/health
# erwartet: {"status":"ok","database":"connected","storage":"connected"}

Zusätzlich im Browser:

• Startseite lädt,
• Anmeldung funktioniert,
• ein bestehender Lauf ist unverändert sichtbar.

Zurückrollen

Es gibt zwei getrennte Fälle — bitte nicht verwechseln:

a) Nur die Anwendungsversion zurücknehmen

Wenn die neue Version fehlerhaft ist, die Daten aber in Ordnung sind:

# in deployment/.env den vorherigen Tag eintragen
#    IMAGE_TAG=0.1.0-alpha.15
bash scripts/deploy.sh

Achtung bei Migrationen

Das funktioniert nur, wenn das Update keine Datenbankmigration enthielt — sonst passt das alte Programm nicht mehr zum neuen Schema. Enthielt das Update eine Migration, brauchst du Fall (b).

b) Datenbank auf den Stand vor dem Update zurücksetzen

bash scripts/deploy.sh --rollback

Das Skript fragt nach Bestätigung und spielt den letzten Schnappschuss vor dem Deploy zurück. Anschließend trägst du wie in (a) den alten IMAGE_TAG ein und deployst erneut, damit Programm und Schema wieder zusammenpassen.

Datenverlust

Ein Rollback der Datenbank verwirft alle Daten, die seit dem Schnappschuss entstanden sind — Einreichungen, Bewertungen, Chatnachrichten. Während eines laufenden Events ist das in aller Regel die schlechtere Option: Erst prüfen, ob sich der Fehler auch vorwärts beheben lässt.

Sicherungen

Vor jedem Deploy legt das Skript automatisch einen Schnappschuss an; die Dumps liegen im Ordner deployment/backups/ und werden 30 Tage vorgehalten. Wie du sie unabhängig davon sicherst und wiederherstellst, steht unter Datenbank.