weirsoe-party-protocol/infra/staging

Staging runbook (Issue #20)

Mål

Staging-miljø for WPP i Proxmox LXC, så release-klar kode kan deployes og smoke-testes sikkert.

Miljø

• LXC: CT 143 (wpp-staging)
• App path: /opt/wpp-staging/app
• Service: wpp-staging.service
• Health endpoint: GET /healthz
• Database: MySQL (staging må ikke bruge SQLite, issue #133)
• Aktuel MVP UI-path: legacy host/player UI (USE_SPA_UI=false)

MVP env-kontrakt

Staging skal mindst have følgende release-relevante env vars sat:

• DB_ENGINE=django.db.backends.mysql
• CHANNEL_REDIS_HOST + CHANNEL_REDIS_PORT
• USE_SPA_UI=false
• WPP_SPA_ASSET_BASE=/static/frontend/angular/browser
• WPP_SPA_ASSET_VERSION=<release-tag eller sha>

USE_SPA_UI=true er ikke del af den primære MVP release-gate. Det hører til separat cutover-verifikation.

Verifikation

Kør fra devops-shell med Proxmox-adgang:

ssh proxmox-lan "sudo -n pct status 143"
ssh proxmox-lan "sudo -n pct exec 143 -- systemctl is-active wpp-staging.service"
ssh proxmox-lan "sudo -n pct exec 143 -- curl -fsS http://127.0.0.1:8000/healthz"

Forventet:

• CT er running
• service er active
• healthz returnerer JSON med ok=true

Smoke-suite skriver nu et gameplay-artifact som JSON under /opt/wpp-staging/app/artifacts/smoke/ (kan overrides via ARTIFACT_DIR/ARTIFACT_FILE).

Før manuel UI-smoke anbefales følgende bootstrap på staging-app'en:

python manage.py bootstrap_mvp

Det sikrer en host-bruger og aktiv demo-kategori/spørgsmål uden ad hoc admin-oprettelse.

For den automatiske MVP bootstrap + smoke artifact flow bruges den kanoniske kommando:

./infra/staging/run_mvp_smoke.sh

Kommandoen kører i staging-CT via Proxmox, loader staging-env, kører bootstrap_mvp, og derefter smoke_staging --artifact .... Som default håndhæver den MVP-pathen USE_SPA_UI=false. Brug kun ALLOW_SPA_CUTOVER=1 ved separat SPA-cutover.

For release-lignende "én kommando" execution bruges wrapperen:

./infra/staging/deploy_and_smoke_staging.sh [ref] [artifact-path]

Efter deploy validerer scriptet, at DB_ENGINE ikke er django.db.backends.sqlite3 før migrations køres.

Deploy-scriptet bruger en release-candidate mappe og promoverer først til /opt/wpp-staging/app efter succesfuld migrate. Det reducerer schema/code drift ved afbrudte deploys (issue #130) og understøtter release-readiness gate (issue #90).

Deploy (canonical execution context)

Deploy skal altid køres via Proxmox host over SSH (ikke fra lokal coder-shell med direkte sudo pct).

Officiel kommando:

./infra/staging/deploy_staging.sh [ref]

Anbefalet release-wrapper:

./infra/staging/deploy_and_smoke_staging.sh [ref] [artifact-path]

Scriptet bruger default PROXMOX_HOST=proxmox-lan og kører sudo -n pct exec på hosten.

Eksempler:

./infra/staging/deploy_staging.sh
./infra/staging/deploy_staging.sh v0.3.0
PROXMOX_HOST=proxmox-prod ./infra/staging/deploy_staging.sh main
./infra/staging/deploy_and_smoke_staging.sh main
./infra/staging/deploy_and_smoke_staging.sh v0.3.0 /opt/wpp-staging/app/artifacts/smoke/release-smoke.json

Smoke (canonical execution context)

MVP smoke skal køres via Proxmox host over SSH, ligesom deploy:

./infra/staging/run_mvp_smoke.sh

Eksempler:

./infra/staging/run_mvp_smoke.sh
./infra/staging/run_mvp_smoke.sh /opt/wpp-staging/app/artifacts/smoke/manual-smoke.json
PROXMOX_HOST=proxmox-prod CT_ID=222 ./infra/staging/run_mvp_smoke.sh
ALLOW_SPA_CUTOVER=1 ./infra/staging/run_mvp_smoke.sh

Policy-kobling

Før deploy:

1. Bekræft at tester ikke er aktiv (ingen aktiv smoke-run).
2. Kør helst ./infra/staging/deploy_and_smoke_staging.sh for release-kandidater.
3. Hvis wrapper ikke bruges: deploy til staging og kør derefter ./infra/staging/run_mvp_smoke.sh.
4. Bekræft MVP UI-smoke på legacy UI (/lobby/ui/host + /lobby/ui/player).
5. Først derefter må release-tag oprettes (se docs/RELEASE_POLICY.md).