A release evidence record connects a proposed change to the artifact deployed and the health observed after exposure. A green CI run tied only to a branch name is weak evidence because the branch, dependencies, and environment can change. The record should identify immutable inputs and the decision that moved them into an environment.
Make this comfortable
Release evidence: tie one deployed digest to one approval decision
Operational decision
A shipment API release packet includes commit, image digest, chart or manifest revision, database migration compatibility, build attestations, security gate result, approving operator, deployment timestamp, and the runtime digest observed in the cluster. The text block is a review schema, not proof that those controls ran. Promote the same image digest tested in staging; change environment configuration through a reviewed revision rather than rebuilding the image. After deployment, read back the running Pods and route a synthetic shipment request through the real edge path. Record both a stop decision and a promotion decision with their thresholds. If the observed digest differs from the approved digest, halt promotion and investigate provenance before deciding that the service looks healthy.
Shipment release packet
Source commit: immutable revision
Artifact: full image digest and build attestation
Configuration: reviewed manifest revision and values checksum
Gate: test, migration compatibility, security result
Decision: named approver, time, environment
Observed runtime: Pod image IDs and edge transaction result
Recovery: previous digest and compatible schema verifiedCost and verification
The packet consumes storage and reviewer time. Automate evidence collection where it reduces transcription error, but keep the approval judgment explicit. Retain records long enough for incident reconstruction and access review; avoid embedding tokens or private customer payloads. A runtime readback closes a common gap between intended and actual deployment. One passing synthetic transaction is a narrow check, so pair it with error and latency monitoring for the rollout window.
Common Mistakes
- Do not approve a mutable tag as the only artifact identity.
- Do not rebuild separately for each environment and call it one promoted artifact.
- Do not treat an approval record as proof that the intended digest ran.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Immutable artifacts and release provenance
- Software supply chain: SBOM and provenance at admission
- Helm release review: render before applying
- Progressive delivery: canary checks and rollback
Practice and check
Cloud authority follow-up
- Temporary sessions: preserve caller lineage through role chains
- Audit trails: prove which data-plane actions are recorded
GitOps operating-boundary follow-up
- GitOps render locks: identify every input behind an applied manifest
- GitOps verification: separate source sync, resource health, and user success
Web publishing follow-up
Delivery measurement follow-up
devops
operations