stwaidele/dorfteich
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases 22 Wiki Activity
340f23fc51
dorfteich/deploy/go-live.md
Claude Fable 5 69e7b1406b
Some checks failed
CD / Build and push images (push) Successful in 1m9s
Details
CI / Lint, typecheck, test (push) Failing after 1m11s
Details
CI / Auth e2e pack (push) Has been skipped
Details
CI / Import/export fidelity gate (push) Has been skipped
Details
CI / Build container images (push) Has been skipped
Details
CD / Deploy to Test (push) Successful in 9s
Details
CD / Smoke tests against Test (push) Successful in 1m13s
Details
CD / Promote to Int (push) Successful in 11s
Details
Move the stage directories to /srv/DOCKER (host consolidation) 
ONE consolidated every Docker stack under /srv/DOCKER (BASEL
convention, tracked in stwaidele/infrastructure-one); the three
Dorfteich stages follow. Deploy targets in cd.yml (test/int) and
prod-deploy.yml plus the docs now point at /srv/DOCKER/dorfteich-<stage>.
Data lives in named volumes keyed by the unchanged compose project
name, so the directory move carries no data migration. The go-live
checklist's uptime-kuma path already lives under /srv/DOCKER — the doc
just catches up.

Deliberately committed together with the host-side move: this commit
must not deploy before the directories exist at the new path.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-14 12:43:29 +02:00

4.4 KiB
Raw Blame History

Go-live checklist — dorfteich.online (issue #89)

The release pipeline and the Prod stack are ready; going live is the operator's call. Executed items carry their date; unchecked items block the DNS switch.

Release mechanics (in place)

  • 2026-07-12 — Release workflow: pushing vX.Y.Z builds the four semver images and publishes a Gitea release whose notes list the changes since the previous release and call out database migrations. (Notes derive from commit subjects — the repo is trunk-based without PRs; the issue's "PR titles" have no source here, documented deviation.)
  • 2026-07-12 — Manual gate + Prod deploy: pushing prod-vX.Y.Z-<suffix> (the human approval — Gitea 1.22 has no environment gates; revisit on 1.23+) verifies the release images exist, pins TAG in the Prod .env, pulls, restarts, and waits for readiness. Re-deploys/rollbacks are new suffix tags on the target release.
  • 2026-07-12 — Prod stack provisioned on ONE (/srv/DOCKER/dorfteich-prod/, ports 8120–8122, secrets generated on the host, full backup profile: 30 d retention, failure mail). The host decision "ONE" is the working default — recorded here; if the owner picks different iron at go-live, the stack directory moves per the restore runbook's relocation procedure.
  • 2026-07-12 — Test release walked the full gate: v0.1.0 built and published → prod-v0.1.0-initial deployed → readyz green.
  • 2026-07-12 — Rollback tested on Prod: v0.1.1 deployed, then prod-v0.1.0-rollback1 returned the stack to v0.1.0, readyz green (one-release downgrade window per docs/self-hosting).

Operator items (block the DNS switch)

  • Prod host decision confirmed (working default: ONE, where Test/Int and the registry already live — one host, no BASEL yet).
  • DNS: point dorfteich.online at ONE (today it still points at the old VPS 188.245.116.44).
  • Caddy: activate the prepared dorfteich.online block in /etc/caddy/Caddyfile on ONE (ports 8120–8122) after DNS, systemctl reload caddy, verify the Let's Encrypt certificate — this also closes the #88 item "ACME exercised on a real domain".
  • First-run setup: run the wizard on the fresh instance (or set the SETUP_ADMIN_* preseed in the Prod .env before first boot) — creates the Site Admin.
  • Prod SMTP: configure a production relay (wizard step or .env); the Prod .env ships without SMTP on purpose.
  • Legal texts (#82): paste the real dorfteich.online imprint and privacy policy in Administration → Legal pages.
  • Monitors (#85, done 2026-07-12): a fresh Uptime-Kuma runs on ONE (kuma.101010.cloud, /srv/DOCKER/uptime-kuma/, bound to 127.0.0.1:8130 behind Caddy). All four Prod monitors from deploy/monitoring.md are live and green (prod web, prod api ready, prod api degraded keyword, prod collab via the /collab/healthz fallback). Alerting goes to the existing Trinity Matrix room (!RtztXRBVkQJgUwpGXx, same channel as the website monitoring, target @stwaidele:trinity.101010.cloud); a test DOWN alert was confirmed delivered. Kuma admin login and the Matrix access token live on the host (admin-password.txt); no off-host Kuma yet (a host-total outage won't self-report).
  • Backups verified on Prod (#87, done 2026-07-12): the drill's DRILL_SOURCE_VOLUME now points at dorfteich-prod_backups (commit a35f713). An on-demand drill against the fresh Prod set 20260712-183629 restored green — readyz ok, 2 users, 16 pages (logged on issue #98). Note: the very first Prod backup (20260712-135349) predated the wizard and had no users, so a drill needs a backup taken after real content exists — trigger "Back up now" once after go-live, as was done here.
  • Off-host mirror (#84, done 2026-07-12): tunnel fixed, BASEL provisioned (deploy/backup-basel.md), mirror live on Test AND on Prod since the v0.2.0 deploy (first run verified: all sets on BASEL, status.json → mirror.lastRun = succeeded).
  • Optional hygiene: a dedicated DEPLOY_SSH_KEY_PROD secret (the workflows currently reuse the host-wide deploy key stored as DEPLOY_SSH_KEY_TEST).