The operational problem
Application code, database state, files, configuration, and running services change at different speeds. A release can appear healthy while using the wrong migration, empty replacement storage, or an incomplete build.
The release controls
- A version tag identifies the exact commit intended for production.
- The complete automated suite must pass before the deployment job begins.
- An immutable archive transfers through a restricted, non-interactive gateway.
- The gateway verifies the release identity and creates a production backup.
- Persistent configuration and named data volumes remain outside the archive.
- Services rebuild and restart through a declared Compose configuration.
- A health check gates success; failure restores the previous application release.
Why the backup belongs in the release path
A backup policy and a deployment backup solve different problems. Scheduled copies protect continuity over time. The pre-release copy establishes a recovery point tied to the exact change being introduced.
Evidence after deployment
The release records its tag, commit, and deployment time. External checks then verify the actual public behavior—not merely container status—including canonical redirects, public pages, crawler files, portal indexing controls, API health, and genuine 404 responses.
The reusable lesson
Release safety comes from a chain of independently useful controls. Tests do not replace backups; backups do not replace health checks; and health checks do not replace an identifiable rollback target.