Release Engineering Roadmap¶
"A build produces a binary; a release produces a promise."
This roadmap is about turning built artifacts into releasable, traceable, reversible deliveries: versioning, changelogs, release branches, signing, registries, rollback, and the audit trail that lets you say with confidence what was shipped, when, and by whom.
Looking for building the artifact (compile, link, package)? See Build Systems.
Looking for deploying the artifact (Docker, Kubernetes, rollout strategy)? See the DevOps section.
For CI/CD pipeline design end-to-end, pair this roadmap with the
ci-cd-pipeline-designskill.For API versioning specifically (HTTP/gRPC contracts, deprecation in transit), pair with the
api-versioningskill.
Why a Dedicated Roadmap¶
Release engineering lives between the build and the deploy, and it is the part teams most often skip until a bad ship forces the lesson. Versioning is policy, not syntax. A changelog is a contract with users. A rollback path is not a fallback — it is part of the release. Understanding releases as a category — semver vs calver, RC promotion, signed provenance, deprecation windows — keeps you fluent across cargo publish, npm publish, mvn release, goreleaser, and whatever the next registry demands.
| Roadmap | Question it answers |
|---|---|
| Build Systems | Can I reproducibly turn my source into a runnable artifact? |
| Testing | Does my code work? |
| Release Engineering (this) | Can I ship that artifact safely, traceably, and reversibly? |
Sections¶
| # | Topic | Focus |
|---|---|---|
| 01 | What Release Engineering Covers | The boundary between Build (artifact production) and Deploy (artifact delivery) |
| 02 | Versioning Schemes | Semver, calver, datever; when each fits; the breaking-change discipline |
| 03 | Changelog Discipline | Keep a Changelog format, conventional commits, automated generation |
| 04 | Release Branches & Trains | Release branches vs trunk-based release tags; release trains (Chrome's 4-week cadence) |
| 05 | Release Candidates & Promotion | RC builds, staging soak, promotion gates from RC to GA |
| 06 | Artifact Signing & SBOMs | Sigstore / cosign, SLSA levels, software bills of materials, supply-chain provenance |
| 07 | Artifact Registries | Container registries, language package registries; immutability and retention |
| 08 | Rollback & Hotfix | Feature flags as rollback, binary rollback, roll-forward vs revert; hotfix branch policy |
| 09 | Deprecation Policy | N+1 / N+2 deprecation, migration windows, communicating breaking changes |
| 10 | Release Notes vs Changelog vs Migration Guide | Three artifacts, three audiences (users, integrators, operators) |
| 11 | Compliance & Audit Trail | Who released what, when, with what approvals; SOX, SOC2 evidence |
| 12 | Anti-patterns | "We'll write the changelog later," version-bump-as-CI-only, no rollback path, surprise breaking changes in patch releases |
Languages¶
The roadmap is policy-centric, but examples cover release tooling for Go (go.mod versioning, ldflags version embedding, goreleaser), Java (Maven Release Plugin, Gradle Release Plugin, Nexus staging), Python (PEP 440, twine to PyPI, build for wheels), Rust (cargo publish, crates.io yank semantics), and JS/TS (npm publish, semantic-release, changesets for monorepos).
Status¶
⏳ Structure defined; content pending.
References¶
- Software Engineering at Google — Winters, Manshreck, Wright (release engineering chapter)
- Continuous Delivery — Jez Humble, David Farley (the canonical text on deployment pipelines and release readiness)
- Keep a Changelog — keepachangelog.com (the de facto changelog format)
- Semantic Versioning — semver.org (the spec, including pre-release and build metadata)
- SLSA Framework — slsa.dev (Supply-chain Levels for Software Artifacts; provenance and signing levels)
Project Context¶
Part of the Senior Project — a personal effort to consolidate the essential knowledge of software engineering in one place.