Files
jobtrackingapp/docs/infrastructure/deployment.md
T

20 lines
2.3 KiB
Markdown

# Deployment
Production prerequisites are Docker Engine/Compose, a reverse proxy, the shared external network, and a server-side `.env` outside the repository. The deploy script links `/opt/job-tracker/shared/.env` into the checkout, builds/tests through Gitea Actions, takes a recovery set, deploys commit-tagged images, and validates `/health`, `/ready`, and `/api/auth/config`.
Recommended sequence: validate configuration → run CI → take/inspect recovery set → deploy → verify liveness/readiness/version → run the authenticated smoke checklist. Do not bypass failed browser or production gates. Keep secrets out of Git and use [environment variables](../configuration/environment-variables.md).
The repository runbooks are [the deployment entry point](../../deploy/README.md), [the first-production deployment procedure](../../deploy/first-production-deployment.md), and [MariaDB bootstrap/migration notes](../../deploy/MARIADB.md). The script is intended for the protected deployment workflow, not for an ad-hoc production shell run.
## Production verification
These checks require an authorised production session and are not replaced by local builds or public health probes:
1. Before replacement, record the current commit/version and application/company row counts, and confirm the recovery set is fresh and restorable. See [operational backups](backups.md).
2. After replacement, confirm `/health` reports the deployed version, `/ready` reports `ready`, and `/api/auth/config` returns the expected public configuration.
3. Sign in with an existing account; confirm application/company counts, Career Profile data (including languages), the application workspace, CV variants/themes, public-CV refresh/PDF, and an existing attachment.
4. Exercise one AI operation, email verification/resend, and each configured OAuth provider only when the required external accounts are available. Record failures without placing provider payloads or credentials in logs or notes.
5. Rehearse failure injection on a disposable Linux Docker host. Roll back the code/image first; restore the database only when data or schema is the confirmed cause. See [disaster recovery and rollback](disaster-recovery.md).
The historical release-review and production-inventory details remain in the pre-cleanup archive; this page is the current operator checklist.