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.

Review a release with conflicting evidence

Parcel is a fictional booking service used throughout these exercises. Its pipeline produces the following release record. The letters are shortened identifiers for this tabletop exercise, not valid digests to paste into a deployment.

Reject the promotion of B for now. The matching source revision explains where the builds started; it does not establish that they produced the same content. Ask the pipeline to promote A, or put B through the required validation as a new artifact. Renaming B to the staging tag would change the label without changing that conclusion.

Now assume production references A. Review configuration 18 separately. If it only changes the replica count, check capacity and downstream connection limits. If it enables a new booking path, staging's disabled-flag test did not exercise that path. The release record needs evidence for the changed behavior, even though the binary is unchanged.

Record evidence against its subject. An image signature can establish that an accepted identity signed a digest under your verification policy. A test report can show which checks ran against that digest. Neither says that the production database endpoint is correct. A reviewer should be able to point to the evidence supporting each approval instead of accepting a single green pipeline badge.

Follow the promotion decision

The two checks after digest equality protect different boundaries. Configuration review happens before rollout; production observation checks what actually happened. A successful deployment command only tells you that the command completed according to its own contract.

For this fixture, start with one production replica while the previous release continues serving. Confirm the image reference and runtime image identity, then send a booking through the intended route. Check that the booking can be retrieved and that errors and latency remain within the release's agreed acceptance bounds. Choose an observation window with enough representative requests; five quiet minutes overnight may exercise less of the application than a minute of daytime traffic.

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

Produce a one-page approval record for digest A, source revision R, configuration 18 and a previous release at digest Z/configuration 17. Include the test-report reference, changed configuration, schema compatibility, rollout cohort, stop condition and recovery owner. Use placeholders for unknown evidence rather than approving it by assumption.

Then handle two changes: the registry has deleted Z, and configuration 18 enables a new write format that Z cannot read. Explain why restoring the old manifest no longer establishes a safe recovery path. Choose whether to postpone, retain a compatible artifact or prepare a forward repair before starting.

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. Add one point for identifying the incompatible write format and one for a stop condition tied to the booking outcome. Rework any missing item before continuing.

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