Build Pipeline and Release Engineering
A build pipeline turns commits into trustworthy artifacts. Laptop builds are for development; CI builds are what users install.
Framework: Software Product Essentials. How-tos: Automated releases, Git release workflow.
Pipeline stages
-
Verify — lint, unit/integration tests, license/secret scans as appropriate
-
Build — produce binaries/packages for each target; stamp build info
-
Prove — smoke-install or
app --version/ doctor on the artifact -
Sign — code sign / notarize / cosign as required
-
Publish — attach to a Git release; push registries; update winget/Homebrew taps
-
Announce — changelog entry; optional update feed publish
flowchart LR
PR[PR checks] --> Main[Main green]
Main --> Tag[Version tag]
Tag --> Build[Matrix build]
Build --> Sign[Sign]
Sign --> Rel[GitHub/GitLab release]
Rel --> Feeds[Update feed + package managers]
Versioning
-
Prefer SemVer for libraries and most apps; CalVer when train-based shipping fits
-
Tags trigger releases (
v1.2.3); avoid shipping untagged “latest only” -
Channels map to branches or tag prefixes—document the rule once
Matrix builds
Build on the OS you support, or cross-compile only when you also test on the target. Windows artifacts should be produced (or at least smoke-tested) on Windows runners when native dependencies demand it.
Secrets and signing keys
-
Store signing certs in CI secret stores / hardware-backed providers
-
Never commit
.pfx/ private keys -
Rotate and document who can cut a release
Promotion
Not every green main commit is a user release:
-
dev/ nightly → automated, lighter gates -
beta→ tagged, wider dogfood -
stable→ explicit promotion, fuller checklist
Checklist
-
CI builds all claimed platforms
-
Build info stamped into artifacts
-
Tests gate release jobs
-
Signing wired for production artifacts
-
Tagged releases with notes + checksums
-
Package registries / winget updated as part of the same train (or clearly scheduled)