Immutable Release Promotion: Binding Git SHA, Staging, and Production

1. Identity Before Deployment A reliable release must answer one question precisely: which source revision is running right now? Branch names and latest tags are not enough. The candidate is bound to an exact Git SHA and the built image receives its own immutable identity.

2. The Same Artifact on Staging and Production Staging provides evidence only when it qualifies the same candidate intended for production: 1. Synchronize the exact SHA. 2. Build an immutable candidate. 3. Deploy it to staging. 4. Run browser, API, and runtime checks. 5. Promote that same candidate without rebuilding from a moving source tree.

3. Release Gates and Safe Rollback Production promotion should be a separate authority boundary with explicit admission criteria. Before promotion, verify staging evidence, environment state, rollback readiness, and candidate identity.

Rollback should target a known previous artifact rather than improvising changes during an incident.

4. Post-Deploy Evidence A green deploy command does not prove that users received the intended version. Verify runtime revision, public routes, critical journeys, and persist the result in a durable release journal.