{"product_id":"canary-release-pipeline-blueprint","title":"Canary Release Pipeline Blueprint","description":"\u003ch3\u003eCanary Release Pipeline Blueprint\u003c\/h3\u003e\n\u003cp\u003eManual 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.\u003c\/p\u003e\n\n\u003ch3\u003ePipeline Stages\u003c\/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eversion-calculate\u003c\/strong\u003e — Semantic versioning derived from commit messages using Conventional Commits. \u003ccode\u003efeat:\u003c\/code\u003e bumps minor, \u003ccode\u003efix:\u003c\/code\u003e bumps patch, \u003ccode\u003eBREAKING CHANGE:\u003c\/code\u003e bumps major. \u003ccode\u003esemantic-release\u003c\/code\u003e or \u003ccode\u003erelease-please-action@v4\u003c\/code\u003e calculates the next version.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003echangelog-generate\u003c\/strong\u003e — Automatically generated from commit messages grouped by type: Features, Bug Fixes, Breaking Changes, Performance Improvements. Links to PR numbers and commit SHAs.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003ebuild-release\u003c\/strong\u003e — Builds the release artifact with the calculated version embedded. \u003ccode\u003e-ldflags \"-X main.version=v2.4.0\"\u003c\/code\u003e for Go. \u003ccode\u003epackage.json\u003c\/code\u003e version update for Node. Version stamped in build metadata.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003esign-artifact\u003c\/strong\u003e — Cosign keyless signing for container images. GPG signing for binary releases. npm provenance for published packages. SHA256 checksums published alongside artifacts.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003epublish\u003c\/strong\u003e — 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.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003egithub-release\u003c\/strong\u003e — \u003ccode\u003egh release create v2.4.0\u003c\/code\u003e with auto-generated release notes, artifact attachments, and checksums. Pre-release flag for release candidates (\u003ccode\u003ev2.4.0-rc.1\u003c\/code\u003e).\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003enotify\u003c\/strong\u003e — Slack message to the releases channel with version, changelog summary, and links. Email to subscribers. Jira version marked as released.\u003c\/li\u003e\n\u003c\/ul\u003e\n\n\u003ch3\u003eSecurity Gates\u003c\/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eSigned releases\u003c\/strong\u003e — Every release artifact has a verifiable signature. Consumers can verify the artifact came from the CI pipeline, not a compromised developer machine.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eProvenance attestation\u003c\/strong\u003e — SLSA Level 3 provenance generated by the CI system. Links the published artifact to the exact source commit and build environment.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eProtected tags\u003c\/strong\u003e — Only the CI pipeline can create version tags. Developers cannot push tags directly, preventing manual version collisions.\u003c\/li\u003e\n\u003c\/ul\u003e\n\n\u003ch3\u003eWhat Breaks First\u003c\/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eNo releasable commits since last tag\u003c\/strong\u003e — All commits since the last release are \u003ccode\u003echore:\u003c\/code\u003e or \u003ccode\u003edocs:\u003c\/code\u003e 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.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003ePre-release version ordering\u003c\/strong\u003e — \u003ccode\u003ev2.4.0-rc.2\u003c\/code\u003e is published after \u003ccode\u003ev2.4.0-rc.10\u003c\/code\u003e but SemVer sorts it before \u003ccode\u003erc.10\u003c\/code\u003e (string comparison). Package managers may serve the wrong version. Fix: use zero-padded pre-release numbers or avoid more than 9 release candidates.\u003c\/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eChangelog merge conflict on main\u003c\/strong\u003e — Two releases in quick succession both modify \u003ccode\u003eCHANGELOG.md\u003c\/code\u003e at the same insertion point. Fix: use \u003ccode\u003erelease-please\u003c\/code\u003e 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.\u003c\/li\u003e\n\u003c\/ul\u003e","brand":"Citadel Cloud Management","offers":[{"title":"Default Title","offer_id":54890411852067,"sku":"CCM-DEV-017","price":39.0,"currency_code":"USD","in_stock":true}],"thumbnail_url":"\/\/cdn.shopify.com\/s\/files\/1\/0979\/8539\/7027\/files\/citadel-devops-product_af25c188-7aa0-4477-81d9-9753ca60a3bd.jpg?v=1775137861","url":"https:\/\/www.citadelcloudmanagement.com\/products\/canary-release-pipeline-blueprint","provider":"Citadel Cloud Management","version":"1.0","type":"link"}