Before deploymentci-artifact-release

Artifact Release Checklist

15 items ·8 critical ·5 warn ·2 info

How to use this checklist

This is what a release is expected to look like before it is allowed to be promoted to production. It assumes the underlying pipeline has already passed the CI Pipeline Security, CI Runner Security, and Supply Chain Security checklists.

Work it through at the moment of release, not after. A release that ships without an immutable tag, without a signature, or without a recorded rollback pointer is a release the next incident will trip over.

Sign-off

Every critical item must pass. A failing critical item blocks the release from being promoted to production; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical8 items

An artifact is built once and promoted across environments by reference (digest, immutable tag). The same SHA is reachable in staging and in production — no rebuild per environment.
Container tags used in production are immutable: pushing the same tag overwrites nothing. Mutable tags like `latest`, `stable`, or `prod` are not used for production pulls; only digests or versioned tags are.
```
crane manifest ghcr.io/&lt;org&gt;/&lt;image&gt;:latest 2>&1 | head; cosign verify ghcr.io/&lt;org&gt;/&lt;image&gt;@sha256:&lt;digest&gt;
```
The registry enforces RBAC: only the build pipeline can push to the production namespace, and only the deploy pipeline (or the GitOps controller) can pull. Read-only for everyone else.
Promotion from staging to production is a single CLI command or a single PR that changes a manifest. Promotion does not require re-running the build, re-signing, or manually re-uploading the artifact.
For every release, the previous release is identified by digest, and a rollback path (`argocd app rollback`, `helm rollback`, or — for Terraform-managed infrastructure — the recorded revert commit of the known-good configuration followed by a fresh reviewed `terraform plan`/`apply` against current state) is recorded. The previous artifact is still in the registry.
A release ships with signed evidence: the signature, the SBOM, and the provenance attestation are all attached to the release or available at a known URL. A release without these artefacts cannot reach production.
No developer uploads to the production registry from a laptop. All production-bound artefacts flow through the CI pipeline; manual uploads are reserved for documented break-glass cases.
Artifact metadata (labels, annotations, manifest) does not embed credentials, tokens, or environment-specific URLs. A `docker inspect` or `crane manifest` of a production artifact must not leak secrets.
```
crane config ghcr.io/&lt;org&gt;/&lt;image&gt;@sha256:&lt;digest&gt; | jq -r ".config.Env // [] | .[]" | grep -E "(KEY|TOKEN|SECRET|PASSWORD|AWS_)" || echo "no secret-shaped env vars"
```

Warning5 items

Releases carry an explicit version (SemVer or CalVer) recorded in a tag, a release, and an annotation on the artifact itself. "Whatever the build produced" is not a version.
A release entry records what changed (commits, PRs, security fixes, breaking changes), who approved, the build pipeline, and the artifact digest. The release notes are not generated by the build; they are owned by the change author.
Release artifacts are retained for a documented period (commonly 90 days for binaries, indefinite for signed release artefacts) and a cleanup policy removes dangling intermediate builds without ever deleting a release.
The registry runs a continuous vulnerability scan on all images, and any image with a known-critical CVE past the team's SLA is blocked from promotion. The scanner covers the registry, not just the build.
A release branch or tag policy is documented: which branches produce release artifacts, who can cut a release, and how hot-fixes are tagged. Hot-fix tags do not bypass the security gates.

Info2 items

Release windows and freeze periods (holidays, end-of-quarter) are defined and enforced by CI: a release attempted outside the window is rejected, not silently shipped.
A discoverable catalogue of released artefacts exists (registry page, internal developer portal, or API). A new engineer can find every production-bound artifact from one place, not by emailing someone.