Build & Release Engineering

A versioning convention: MAJOR.MINOR.PATCH. PATCH: backward-compatible bug fixes. MINOR: backward-compatible new features. MAJOR: breaking changes. Pre-release: 1.0.0-alpha.1, 1.0.0-rc.1. Enables dependency managers to understand compatibility.

"We follow SemVer strictly for our public API library. Changing a function signature is MAJOR — consumers would break. Adding a new optional parameter is MINOR. Fixing a memory leak is PATCH. When we released 2.0.0, we maintained a 1.x branch for 12 months with security patches (PATCH increments) to give consumers migration time."

A repository for storing versioned build artifacts: Docker images (Docker Hub, ECR, GCR), package archives (npm, PyPI, Maven, NuGet), generic binaries. Provides versioning, access control, vulnerability scanning, and promotion workflows.

"Our artifact registry (JFrog Artifactory) is the single source of truth for deployable artifacts. The CI pipeline builds the Docker image, tags it with the commit SHA and semantic version, pushes to the registry. Deployments pull from the registry — never build from source. The registry enforces that every image has passed the security scan before being promotable to production."

A scheduled release cadence where a release ‘train’ departs at a fixed time regardless of whether a specific feature is ready. Teams must have features merged by the cut-off or wait for the next train. Predictable rhythm; misses are planned, not chaotic.

"We run a two-week release train: the release branch is cut on Wednesday; testing and stabilisation through Friday; production deploy on Monday. If your feature isn’t merged by Wednesday, it catches the next train in two weeks. No more ‘hold the release for my feature’ — the train departs on schedule."

Applying a specific commit from the main branch to a release branch without merging the entire development history. Used for hotfixes: the fix is developed on main (or a hotfix branch), then cherry-picked to the release branch to include only that change.

"A critical auth bug was found the day before the v3.2.0 release. We fixed it on main with a small, focused commit. The release manager cherry-picked that single commit to the release/v3.2.0 branch — no other in-progress features were included. After verification on staging, the cherry-picked build became the release artifact."

A build that produces byte-for-byte identical output given the same source code and build environment. Prevents ‘it works in CI but not in production’ from build-time differences, and enables verification that an artifact was built from claimed source code.

"After a supply chain incident in the industry, we invested in reproducible builds. Our Go binaries are built with a fixed GOFLAGS, a pinned toolchain version in go.mod, and SOURCE_DATE_EPOCH set for deterministic timestamps. Two engineers can build from the same commit and get identical SHA256 hashes. This means a compromised CI can’t inject code silently."

A pre-release version that is considered feature-complete and potentially releasable pending final testing. Named versions: v2.0.0-rc.1. If no blocking issues are found, the RC becomes the GA release; if issues are found, a new RC is cut with fixes.

"v4.0.0-rc.1 was distributed to enterprise beta customers for validation. After two weeks, three bugs were reported. We fixed them, cut v4.0.0-rc.2, and ran another week of beta testing with no blocking issues. v4.0.0-rc.2 was promoted to v4.0.0 GA with no further code changes — only the version tag was updated."

Automatically generated release documentation derived from conventional commits (feat, fix, chore, BREAKING CHANGE) or PR labels. Tools like semantic-release and release-please parse commit messages to determine version bumps and generate changelogs.

"We use Conventional Commits + semantic-release: every commit is tagged feat:, fix:, or chore:. At release time, semantic-release parses the commits since the last tag: new feat: commits → MINOR bump, fix: commits → PATCH bump, BREAKING CHANGE footer → MAJOR bump. The CHANGELOG.md is generated automatically. Human-written release notes are only for major versions."