Release Automation Checklist
A release is more than a build artifact with a version number. Users need to know what was built, where it came from, and whether the published files match what the project intended to ship.
A practical release pipeline prepares four things before the first tag: signing material, workflow steps, optional package-channel support, and verification commands.
Signing Material
Artifact signing needs a private key available to automation and a public key available to verifiers.
A typical setup has these parts:
| Item | Purpose |
|---|---|
| GPG key | Signs release checksums or artifacts. |
| Key identifier or fingerprint | Lets automation select the intended signing key. |
| Private key secret | Lets CI import the signing key during the release job. |
| Passphrase secret | Unlocks the private key when one is configured. |
| Published public key | Lets users verify signatures after downloading artifacts. |
The private key is operationally sensitive. It should live in CI secrets, not in the repository.
Workflow Steps
A release workflow commonly imports the signing key before running the release tool. It can also install tooling that produces a software bill of materials.
The durable order is:
- Import or unlock the signing key from secrets.
- Build the release artifacts.
- Generate metadata such as checksums or an SBOM.
- Sign the relevant release output.
- Publish artifacts and metadata together.
That order gives downstream users something concrete to verify.
Tag-Driven Releases
Many pipelines treat a Git tag as the release trigger:
git tag v0.1.0
git push origin v0.1.0
If a release fails before publication is trusted, a project may delete and recreate the tag. That should be done carefully because tags are names other tools may already have observed.
git tag -d v1.0.1
git push --delete origin v1.0.1
git tag v1.0.1
git push origin v1.0.1
The safer habit is to treat published tags as durable once other people may have consumed them.
Verification
A release is not complete when CI turns green. Verify the artifacts from the outside:
- Check that signatures validate against the expected public key.
- Inspect container manifests when multi-architecture images are published.
- Confirm that SBOM files are present when the release promises them.
- Test package-manager installation paths that users are expected to use.
Verification closes the loop between release automation and user trust.