SOP: Deploying to production

This SOP is thin on purpose. The procedure lives in erudeon/passtheyear/docs/OPERATIONS.md, section 4. This page says who may do it, when, and what has to be true first.

Purpose

Put a named release onto the production box, deliberately.

Scope

Production only. Staging deploys itself on every merge to main and needs no procedure.

The governing fact

Nothing in CI can reach production. A human runs the deploy over SSH, and that is enforced rather than merely intended. Anybody proposing to automate this is proposing to remove a control, not to save a step.

RACI

Step	Responsible	Accountable	Consulted	Informed
Preflight	Bence	Bence	—	—
Deploy	Bence	Bence	—	—
Verify	Bence	Bence	—	—
Roll back if needed	Bence	Bence	—	—

Steps

1. Preflight

• Who: Bence
• When: before every production deploy, without exception
• How: ops/release/preflight.sh in the code repository. It reads the version and tells you which tag to deploy.
• Output: a confirmed tag, and confidence the box is in a known state

2. Deploy

• Who: Bence
• When: deliberately, not at the end of a long day
• How: ops/release/deploy.sh <tag> over SSH. See docs/OPERATIONS.md.
• Output: production running the named tag

3. Verify

• Who: Bence
• When: immediately after
• How: ops/release/audit.sh reports what the box is actually running, read back from the image label. Do not verify by loading the site and forming an impression.
• Output: confirmation the intended version is the running version

Exceptions

Situation	What to do
It is worse after deploying	ops/release/rollback.sh. Roll back first, diagnose second
A database migration is involved	Read section 5 of docs/OPERATIONS.md before starting. Migrations have their own safety contract and are not part of a routine deploy
The deploy is to fix a live incident	Declare the incident first. See operations/incidents/README.md

Related

• erudeon/passtheyear/docs/OPERATIONS.md — the procedure, the topology, rollback
• releasing-a-version.md — how the tag came to exist