Choose a protected location for deployment records and a safe way to identify the active release. Do not include secrets or customer data in the identifier.

1. Record the commit, artifact checksum, build time and deployment environment. Include the operator or workflow identity that initiated the change.

2. List migrations, significant configuration changes and worker restarts as references or safe names rather than full secret values.

3. Record preparation, activation, verification and any recovery result with timestamps. Distinguish a failed attempt from a successfully active release.

4. Expose only a non-sensitive release identifier through an authenticated diagnostic or deliberately safe status response when useful.

5. Retain enough history to match incidents and backups with releases. Remove temporary detailed logs according to the agreed retention policy.

Keep a protected phase record for each deployment. This abbreviated example uses fictional release names.

Do not label the server as release 18 merely because its upload finished. Update the active identifier after the actual switch and record rollback activation as another event. Keep the detailed error in private logs, linked by a safe request or deployment ID.

During a test incident, use the record to identify the active code and its compatible recovery artifact. Confirm the record is updated after a rollback as well as a forward deployment.

If the displayed version disagrees with the deployment log, investigate stale processes, caches or multiple instances. A manually edited version label can conceal rather than solve that mismatch.

• Building a deployment artifact in CI
• Preventing simultaneous deployment jobs
• Verifying a deployment with application smoke checks
• Deploying with a release directory and a controlled switch

• GitHub deployment history
• OWASP logging