Promote the artifact you actually tested

TL;DR: Build an artifact once, identify it by immutable content and carry its test evidence into each deployment decision.

Where you are. Begin Safe Delivery after the service-readiness review. This lesson defines what moves through the pipeline before introducing its permissions.

Rebuilding changes the thing being approved

Parcel passes staging tests, then production rebuilds the same source commit. A dependency range resolves differently and the new build contains different bytes. The team has tested one artifact and deployed another, even though both carry the same commit label.

Use an immutable artifact identifier, such as an image digest, in the release record. Record the source revision, build inputs, builder identity and test results associated with that artifact. A mutable tag can remain a convenience label, but it should not be the only evidence of what production ran. The SLSA specification describes provenance for software artifacts; provenance records origin and build facts rather than proving application correctness.

Keep configuration visible

Promoting identical image bytes does not make staging and production identical. Configuration, credentials, runtime limits and data can differ. Keep environment-specific configuration versioned or otherwise auditable, and pair its identifier with the artifact in the release record. A feature flag can change user behavior without rebuilding the application.

In the exercise, staging uses digest A with configuration revision 17. Production is proposed to use digest A with configuration revision 18. The artifact evidence transfers, but the configuration difference still needs review. If revision 18 changes the database endpoint, the team must verify that endpoint's identity and schema compatibility.

Make rollback a reference, not a recollection

Keep the previous release's artifact and configuration available for the agreed recovery period. A rollback that depends on rebuilding an old commit can fail because dependencies disappeared or the builder changed. Retention is part of the release contract.

The release record also needs an operator and an observation window. “All tests passed” does not establish that the traffic switch succeeded. Verify which digest is running and whether the service objective holds for a comparable workload. In an interview, show the record you would inspect when an incident begins; it should answer what changed without reconstructing the pipeline from memory.

Do this before moving on

Write a release record for digest A, source revision R, configuration 18 and a previous release at digest Z/configuration 17. List the evidence that transfers from staging and the evidence that must be collected after promotion.

Expected: tests tied to A transfer; configuration compatibility, actual running digest and production service behavior require verification. Reject a production rebuild even if it uses R unless it produces an artifact whose evidence is independently established. Score one point each for immutable identity, configuration scope and recoverable previous release.

Go deeper

• Artifact identity explains why promotion should preserve tested bytes.
• State and drift extends the same review discipline to infrastructure changes.
• Release versus deploy separates installed code from user-visible behavior.

Key takeaways

• Source revision alone does not identify built bytes.
• Configuration changes need their own review evidence.
• Retain the exact previous release for recovery.

Check yourself

Say it before you reveal it. Pulling the answer out of your own head is what fixes it. Nodding along to someone else's does nothing.

1. 1Same commit, different build bytes means:

   The staging result proves productionA different artifact needs evidenceThe digest can be ignored

2. 2What does provenance not prove?

   Answer it, then reveal