Release Engineering

Hermetic builds, binary provenance, self-service pipelines, and the SRE Book's four principles that make releases boring by design.

Overview

Release engineering as a discipline

SRE Book Chapter 8 defines release engineering as "a specific job function and a set of best practices used by software companies to build and deliver software." It sets out four principles.

> [!IMPORTANT] Binary provenance links a production binary back to a specific source commit, build environment and test run. Without it, you cannot answer "what exactly is running in production right now?"

The four principles

Self-service — Development teams release their own software with centralized tooling built by release engineering, so release engineers are not a bottleneck
High velocity — Frequent releases make each one smaller and lower-risk
Hermetic builds — The build is fully specified, self-contained and reproducible: no external dependencies at build time, no "works on my machine"
Enforcement of policies — Security scanning, test gates and compliance checks are baked into the pipeline through process rather than fiat, not bolted on as manual approvals

Why provenance matters

Production binary — Source commit
Production binary — Build environment
Production binary — Test run

Provenance is the artifact that makes all four principles auditable.

Key concepts

Hermetic build: A build where all inputs (source, dependencies, toolchain) are pinned; same inputs always produce the same binary. No network access during build.
Binary provenance: Cryptographic metadata linking a production artifact to the exact source commit, build environment, and test run that produced it. Enables "what is running in prod?"
Self-service model: Development teams own their release cadence using shared tooling; release engineers build the platform, not the release. Eliminates the bottleneck of a dedicated "release team."
Enforcement through process: Security scans, test gates, and compliance checks are automated pipeline stages — they cannot be bypassed. Policy is code, not a checklist.
Flagged release: Code that is deployed but not yet active, controlled by feature flags. Separates deployment (binary in production) from release (feature available to users).

When to use it

"How do you ensure what deploys to prod matches what was tested?" — hermetic builds + provenance
Designing a release system for a team growing from 10 to 100 engineers
Explaining why frequent small releases are safer than infrequent large ones
Justifying investment in build infrastructure vs. accepting slow, unreliable pipelines

Interview questions

What does "hermetic build" mean and why does SRE care about it?
Why are frequent small releases safer than infrequent large releases, from an SRE perspective?

Release Engineering

Overview