Ship an artifact you can identify and undo

Build once from a pinned revision

Identify the release candidate by commit and build it in a controlled environment with locked dependencies. Assign the resulting binary, package, or container an immutable digest. Promote that same artifact through staging and production rather than rebuilding from the same source in each environment. Otherwise environment drift can produce different bytes under the same version label.

Record compiler or runtime version, dependency lock, build workflow, configuration boundary, test results, and digest. Keep secrets and environment-specific values outside the artifact where the platform allows it. An agent can prepare this packet, but its prose is not a substitute for independently verifiable identifiers.

Attach provenance with the right claim

GitHub documents artifact attestations that establish build provenance for binaries and container images. Verification can connect an artifact to a workflow and source identity. That is useful supply-chain evidence, but provenance does not establish that the source is correct, the tests are sufficient, or the deployed configuration is safe. Treat it as one link in the chain, alongside review and runtime evidence.

Verify signatures and signer identity where attestations are used; storing an unverified statement adds little assurance. Preserve the verification command and result with the release record, and define what happens when verification is unavailable or fails.

GitHub artifact attestations ↗

Roll out against explicit stop conditions

Use a staged exposure appropriate to the service: internal environment, small canary, region, tenant cohort, or percentage. Define health signals and observation windows before deployment. Include correctness signals, not only process liveness: failed jobs, error classes, business invariant checks, queue age, and user-path probes. Name the person authorized to continue, pause, or reverse.

Kubernetes Deployments illustrate versioned rollout status and revision-based rollback, but the documentation also notes that rollback covers the Pod template revision. It does not automatically reverse an external database migration or repair data written under new semantics. The application, data, and configuration rollback plans must agree.

Kubernetes Deployments and rollback ↗

Rehearse the command and the decision

Before release, run the rollback procedure in a safe environment using the actual previous artifact and representative configuration. Measure how long service recovery takes and verify that old code can read current data. Define a point of no return for incompatible writes or migrations. If rollback after that point requires restore or roll-forward repair, call it that and provide the separate runbook.

A compact release packet contains artifact digest, source revision, attestations, checks actually run, approvals, staged observations, rollback target and command, data compatibility, and remaining risks. Preserve the previous artifact for at least the defined recovery window and verify the registry or storage retention policy will not delete it early. Record feature-flag and configuration versions too, because restoring code alone may not restore behavior. No deployment or rollback was performed for this article. The value is a record that lets another operator identify what is running and act without reconstructing an agent conversation.