Release Engineering
Release engineering turns source code into identifiable, tested software that can be delivered repeatedly. It connects version control, builds, testing, packaging, approval, deployment, and recovery into one controlled path.
itDevOps and software delivery | OpenSkills.info
Course pathWalk it in order
Look it upDip in anytime
Go furtherLeaves this page
Don't Panic
Don't Panic — Release Engineering
Release engineering is the discipline that turns a chosen source revision into software that can reach users without the organization having to conduct an archaeological dig when it misbehaves. It exists because “run the build and deploy it” is not a record, a safety argument, or a recovery plan. Before this discipline has done its work, a release is often a sequence of remembered steps performed by whichever machine happened to be awake.
The central character is the artifact: the package, image, archive, or other output built from a specific revision. Give it an immutable version or digest, then build it once and promote those same bytes through environments. This is less romantic than rebuilding for staging and production, but test results describe particular bytes. A shared label cannot persuade different bytes to become the ones that were tested. Labels communicate meaning; a digest identifies the artifact.
Next come the gates, which are checks or approvals that decide whether a release candidate may move on. Review, tests, policy checks, and provenance all count as evidence when they name the candidate they examined. Change the source, configuration, or artifact after a gate passes and the old evidence has politely become evidence about something else. Release engineering keeps that awkward fact visible instead of letting it hide inside a cheerful green dashboard.
Deployment and release are related but are not twins. Deployment puts software in an environment. Release makes behavior available to users. A canary exposes a candidate to a limited population for a limited time, compares useful signals with a control, and expands only when the evidence holds. Feature flags can separate deployment from release, which is handy, but they are configuration too. They need ownership, observation, and removal, because abandoned switches breed in the dark.
Recovery is not the emergency chapter at the back. It belongs in the release design. A rollback restores a previous artifact or configuration; a roll forward deploys a corrective change. Database and state changes can make rollback unsafe, so compatible changes and rehearsed recovery matter before production has opinions about the matter.
Read the Intro for the full release path and its vocabulary. Use Slides for the relationships among artifacts, gates, promotion, and rollout. Keep the Cheatsheet nearby when comparing rollout choices or building a release record. The Quiz checks whether the evidence chain still joins up. The Field Notes covers the expensive mistakes that a passing pipeline can conceal.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://sre.google/sre-book/release-engineering/
Supports
- release engineering scope from source control through build, test, packaging, and deployment
- self-service, high velocity, hermetic builds, policy enforcement, and release records
- build identification, release branching, testing packaged artifacts, configuration strategies, and risk-based rollout
- https://sre.google/workbook/canarying-releases/
Supports
- reproducible, automated, tested, and small release principles
- canary definition, control comparison, evaluation requirements, traffic limits, and rollout metrics
- feature flags, blue-green deployment, recovery, and production testing limits
- https://reproducible-builds.org/docs/
Supports
- reproducible build definition and sources of environmental variance
- deterministic output, defined build environments, checksums, and signatures
- https://slsa.dev/spec/v1.2/
Supports
- SLSA version 1.2 tracks and incremental supply-chain guarantees
- provenance, attestation formats, artifact production, distribution, and verification
- https://semver.org/
Supports
- declared public API requirement
- major, minor, and patch version meanings
- https://dora.dev/guides/dora-metrics/
Supports
- throughput and instability categories
- change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate
- application or service scope and trend-based interpretation
- https://github.com/sindresorhus/awesome
Supports
- starting point for awesome-list discovery
- https://github.com/wmariuss/awesome-devops
Supports
- ecosystem discovery of Tekton, Dagger, Flagger, Unleash, and GoCD as continuous integration and delivery tools
- https://tekton.dev/docs/getting-started/pipelines/
Supports
- Tekton pipeline composition from tasks and pipeline runs on Kubernetes
- https://docs.dagger.io/
Supports
- Dagger as a programmable, local-first software delivery platform using containerized functions
- https://docs.flagger.app/
Supports
- Flagger progressive delivery and automated canary, blue-green, metric, and test evaluation
- https://docs.getunleash.io/guides/gradual-rollout
Supports
- gradual feature rollout, targeting constraints, stickiness, and rollback controls
- https://docs.gocd.org/current/introduction/concepts_in_go.html
Supports
- GoCD tasks, jobs, stages, pipelines, materials, artifacts, dependencies, and value-stream maps
- https://agilemanifesto.org/
Supports
- publication of the Agile Manifesto in February 2001 and its principle of frequent delivery of working software
- https://semver.org/spec/v1.0.0.html
Supports
- Semantic Versioning 1.0.0 publication in June 2009
- https://docs.docker.com/engine/release-notes/prior-releases/
Supports
- Docker Engine 1.0.0 release on June 9, 2014 with production support
- https://research.google/pubs/making-push-on-green-a-reality-issues-actions-involved-in-maintaining-a-production-service/
Supports
- Google's 2014 Push On Green account of automating repeatable rollout steps and approvals
- https://research.google/pubs/release-engineering-2/
Supports
- 2016 publication of Google's Release Engineering chapter in the Site Reliability Engineering book
- https://github.blog/changelog/2018-10-16-github-actions-limited-beta/
Supports
- October 2018 public beta of GitHub Actions for build, package, release, update, and deployment workflows
- https://github.blog/changelog/2019-11-11-github-actions-is-generally-available/
Supports
- November 2019 general availability of GitHub Actions
- https://slsa.dev/blog/2023/02/slsa-1-0-rc
Supports
- SLSA v0.1 release in June 2021
- https://slsa.dev/blog/2023/04/slsa-v1-final
Supports
- SLSA v1.0 final release on April 19, 2023 and its stable Build track
- https://docs.github.com/actions
Supports
- GitHub Actions workflow automation and CI/CD documentation
- https://docs.gitlab.com/ci/
Supports
- GitLab CI/CD pipeline documentation
- https://www.jenkins.io/doc/
Supports
- Jenkins pipeline and automation documentation
- https://buildkite.com/docs/pipelines
Supports
- Buildkite pipeline documentation
- https://circleci.com/docs/
Supports
- CircleCI pipeline and execution-environment documentation
- https://developer.harness.io/docs/continuous-delivery/
Supports
- Harness continuous delivery and verification documentation
- https://spinnaker.io/docs/
Supports
- Spinnaker delivery pipeline documentation
- https://argo-cd.readthedocs.io/
Supports
- Argo CD desired-state reconciliation documentation
