Canary Release Pipeline Blueprint

Canary Release Pipeline Blueprint

Manual release processes are where version numbers go to die. I have seen teams where the "release process" was a developer updating a version string in three different files, manually writing a changelog from memory, tagging the commit, and hoping the CI pipeline picked it up. At one enterprise, two developers tagged different commits as v2.3.0 on the same day because there was no automated versioning. This template automates the entire release lifecycle: version calculation, changelog generation, artifact publishing, and release notes.

Pipeline Stages

• version-calculate — Semantic versioning derived from commit messages using Conventional Commits. feat: bumps minor, fix: bumps patch, BREAKING CHANGE: bumps major. semantic-release or release-please-action@v4 calculates the next version.
• changelog-generate — Automatically generated from commit messages grouped by type: Features, Bug Fixes, Breaking Changes, Performance Improvements. Links to PR numbers and commit SHAs.
• build-release — Builds the release artifact with the calculated version embedded. -ldflags "-X main.version=v2.4.0" for Go. package.json version update for Node. Version stamped in build metadata.
• sign-artifact — Cosign keyless signing for container images. GPG signing for binary releases. npm provenance for published packages. SHA256 checksums published alongside artifacts.
• publish — Multi-target publish: container to registry, binary to GitHub Releases, package to npm/PyPI/crates.io, Helm chart to chart repository. Each target published in parallel.
• github-release — gh release create v2.4.0 with auto-generated release notes, artifact attachments, and checksums. Pre-release flag for release candidates (v2.4.0-rc.1).
• notify — Slack message to the releases channel with version, changelog summary, and links. Email to subscribers. Jira version marked as released.

Security Gates

• Signed releases — Every release artifact has a verifiable signature. Consumers can verify the artifact came from the CI pipeline, not a compromised developer machine.
• Provenance attestation — SLSA Level 3 provenance generated by the CI system. Links the published artifact to the exact source commit and build environment.
• Protected tags — Only the CI pipeline can create version tags. Developers cannot push tags directly, preventing manual version collisions.

What Breaks First

• No releasable commits since last tag — All commits since the last release are chore: or docs: which do not trigger a version bump. The pipeline runs but produces no release. Fix: add a pipeline check that skips the release workflow if no version bump is needed.
• Pre-release version ordering — v2.4.0-rc.2 is published after v2.4.0-rc.10 but SemVer sorts it before rc.10 (string comparison). Package managers may serve the wrong version. Fix: use zero-padded pre-release numbers or avoid more than 9 release candidates.
• Changelog merge conflict on main — Two releases in quick succession both modify CHANGELOG.md at the same insertion point. Fix: use release-please which manages the changelog in a PR and rebases automatically, or generate the changelog at release time from git history rather than maintaining a static file.