Release Engineering

Senior-to-principal release engineering methodology: designing and operating the pipelines, processes, artifacts, gates, compliance evidence, and metrics that move software from commit to customer safely, predictably, and fast.

Ownership

You own	You don't own
Release process design — branch strategy, process model, release cadence	Application feature implementation — route to backend-engineering / frontend-engineering
CD pipeline architecture — build-once promotion stages, gates, push-on-green	Production incident root-cause debugging — route to systematic-debugging
Progressive delivery — canaries, rings, percentage rollouts, feature flags	On-call and SLO operations — route to site-reliability-engineering
Versioning and artifacts — SemVer, conventional commits, changelogs, immutability, provenance	Security implementation and threat modeling — route to secure-software-engineering
Readiness and quality gates — release candidates, go/no-go, sign-off	Internal developer platform construction — route to platform-engineering
Rollback and recovery planning — runbooks, rehearsals, recovery targets	Data pipeline operations and schema migration engineering — route to data-engineering
Change governance and audit compliance — SOC 2 / SOX / PCI evidence chains	Spec authoring and SDD gate mechanics — route to spec-driven-development
DORA metrics — definitions, computation, thresholds	API contract design and versioning policy — route to api-design-and-evolution
Multi-team release coordination — trains, calendars, stabilization	Evidence collection and verdicts against explicit criteria — route to verification-methodology
Release operations — branch cuts, pipeline triage, emergency releases	Runtime monitoring and alerting — that's SRE

Core Principles

Build once, promote many. The artifact that passed every gate is the only artifact that ships. Rebuilding per environment reintroduces risk and invalidates what was verified.

Small batches ship faster and safer. Trunk-based development with frequent small merges outperforms long-lived branches on every DORA metric — deployment frequency, lead time, change failure rate, and recovery time.

Decouple deploy from release. Deploying code to production is not the same as exposing it to users. Feature flags and progressive rollout separate the two so each can happen on its own timeline and either can be reversed independently.

Automated safety beats approval bureaucracy. Evidence-based controls and pipeline gates outperform change-advisory-board sign-off, which research correlates with slower, less stable delivery. Automate the checks; reserve human approval for genuinely exceptional change.

Rehearse rollback. A rollback you haven't practiced will fail under pressure. Rollback is a first-class release artifact with its own runbook, trigger thresholds, and rehearsal log.

Verify in production. Staging parity helps, but production canaries, smoke tests, and observability gates are where readiness is actually proven. Real traffic, real telemetry, real decision points.

Protect the supply chain. Sign every artifact, record provenance and SBOM data, and treat registries as a security boundary. Integrity is part of the release, not an add-on.

DORA is a system outcome. Speed and stability emerge from how the process is designed — batch size, architecture, automation, safety culture — not from chasing metric targets.

Loading Guide

File	Load when
references/role-and-career.md	Understanding the release engineering role — org placement, day-to-day, Senior/Staff/Principal leveling, and evidence separating levels
references/skills-competency-model.md	Mapping the technical and professional skills release engineers master, and which ones differentiate at senior and above
references/release-process-models.md	Choosing a process model — trunk-based, GitFlow, GitHub Flow, release branches, release trains — and matching cadence to the org
references/cd-and-pipeline-stages.md	Designing CD pipelines — build-once promotion, stage gates, push-on-green, pipeline-as-code, hermetic builds, environment parity
references/progressive-delivery.md	Planning canary, blue/green, ring, or percentage rollouts; metric and error-budget gates; auto-rollback triggers
references/change-governance-and-compliance.md	Building audit-ready change control — SOC 2 CC8.1, SOX ITGC, PCI back-out, evidence chains, separation of duties, emergency change
references/readiness-and-quality-gates.md	Defining readiness dimensions, release candidates, go/no-go structure, error-budget release policy, definition of done
references/rollback-and-recovery.md	Planning rollback vs roll-forward vs flag recovery per system type; rehearsed rollbacks; time-boxed decisions; quarantine
references/versioning-and-artifacts.md	Setting SemVer/CalVer policy, conventional commits, changelog conventions, artifact immutability and provenance
references/feature-flag-lifecycle.md	Running flags through their full lifecycle — create, guard, rollout, verify, remove, expire — and avoiding flag debt
references/monorepo-polyrepo-release.md	Choosing mono vs polyrepo release strategy, affected-build detection, topological publish order, release tooling
references/toolchain-landscape.md	Selecting tools by category — CI/CD, release automation, artifact repos, GitOps, feature flags (2025-2026 status)
references/supply-chain-security.md	Hardening the supply chain — SLSA, SBOM, sigstore keyless signing, dependency updates, provenance attestations
references/metrics-and-dora.md	Defining and computing the five DORA metrics, thresholds, vendor divergence, and measurement pitfalls
references/release-operations-and-triage.md	Running release trains end-to-end — branch cuts, stabilization, go/no-go, pipeline triage, release infra reliability, agentic automation
templates/release-plan.md	Producing a release plan — scope, milestones, owners, risks, rollout, rollback contingency, comms
templates/release-readiness-checklist.md	Running a readiness review — checkbox table by dimension with owner + evidence, go/no-go block
templates/rollback-runbook.md	Writing a rollback runbook — triggers, per-layer steps, verification, ordering, comms, rehearsal log
templates/release-notes.md	Drafting release notes — version, date, change-type sections, breaking changes, migration steps
templates/change-governance-record.md	Recording an audit-ready change — ticket, PR, CI runs, artifact digest, deploy timestamp, verification, emergency flag
templates/hotfix-emergency-release-plan.md	Planning an emergency release — severity, break-glass approvals, expedited path, post-implementation review
assets/dora-metrics-reference.md	Looking up the five DORA metrics — formulas, units, data sources, thresholds, pitfalls — in one page
assets/versioning-decision-table.md	Choosing a versioning scheme — SemVer vs CalVer vs independent vs one-version, bump rules
assets/deployment-strategy-matrix.md	Comparing deployment strategies — rolling, blue-green, canary, ring, flag, shadow — on speed, safety, rollback
assets/release-toolchain-cheatsheet.md	Quick tool lookup by category — one-liner and when-to-pick per tool
scripts/version_bump.py	Computing the next SemVer from conventional commits or a git range
scripts/semver_check.py	Validating, comparing, or sorting strict SemVer versions
scripts/changelog_check.py	Validating Keep a Changelog or Release Please CHANGELOG.md files
scripts/dora_metrics.py	Computing the five DORA metrics from deployment and commit event data
scripts/release_plan_scaffold.py	Scaffolding a release plan document from flags or a git range
evals/evals.json	Running output-quality evals for this skill (schema v1, 8 cases)

Adjacent Skills

• Use qa-methodology to define test strategy, regression scope, flake policy, and quality-gate semantics. This skill combines the resulting evidence with operational and governance evidence for a release decision.
• For AI-agent releases, use agent-evals-and-observability to design and interpret behavioral, trajectory, and model-regression evidence before incorporating it into a release gate.

Scripts

Script	Invocation	Purpose
version_bump	python3 scripts/version_bump.py --current-version 1.4.0 --git-range v1.4.0..HEAD	Computes the next SemVer from Conventional Commits — breaking → major (minor in 0.x), feat → minor, fix → patch; optional prerelease tag
semver_check	python3 scripts/semver_check.py --check 1.2.3-beta.1	Validates strict SemVer 2.0.0, compares two versions, or sorts a list
changelog_check	`python3 scripts/changelog_check.py CHANGELOG.md [--format auto	keep-a-changelog
dora_metrics	python3 scripts/dora_metrics.py --events events.json	Computes all five DORA metrics from deployment and commit event data
release_plan_scaffold	python3 scripts/release_plan_scaffold.py --version 2.0.0 --owner alice --output plan.md	Scaffolds a release plan document with filled placeholders from flags or a git range

Triggers

Load this skill when the task involves:

• Release planning — designing a release plan, timeline, milestones, or rollout strategy
• Pipeline design — architecting or reviewing CD pipelines, promotion stages, or push-on-green
• Version bumps — computing the next version, SemVer validation, conventional-commit classification
• Changelogs — authoring or validating a changelog
• Readiness review — go/no-go calls, release candidates, readiness checklists
• Rollback planning — writing or rehearsing rollback runbooks and recovery plans
• Progressive delivery — canaries, rings, percentage rollouts, traffic shadowing
• Feature flags — flag rollout, lifecycle, and cleanup
• Release trains — calendar releases, branch cuts, stabilization windows
• DORA metrics — defining, computing, or reporting the five DORA metrics
• Compliance evidence — SOC 2 / SOX / PCI change records, audit trails, separation of duties
• Artifacts and supply chain — SBOM, provenance, signing, registry hygiene
• Emergency releases — hotfixes, break-glass changes, expedited release paths
• Multi-team coordination — cross-team release calendars and integration stabilization

When not to use

Route to the named sibling skill instead:

• backend-engineering / frontend-engineering — implementing application features. Release engineering designs the pipeline that ships code; it does not implement the code itself.
• systematic-debugging — root-cause analysis of production incidents, fault localization, bug reproduction. Release engineering plans recovery; debugging finds the cause.
• site-reliability-engineering — on-call operations, SLO/error-budget management, capacity planning, and day-to-day incident response.
• secure-software-engineering — security implementation and threat modeling. Release engineering consumes security controls (SBOM, signing, dependency scanning) but does not design them.
• platform-engineering — building the internal developer platform: CI infrastructure, GitOps controllers, self-service tooling, and golden paths.
• data-engineering — data pipeline operations, schema migration engineering, and data quality monitoring.
• spec-driven-development — writing specifications and running SDD pipeline gates and verdicts.
• api-design-and-evolution — API contract design and versioning policy. Release engineering version-bumps artifacts; it does not set API evolution rules.
• verification-methodology — collecting evidence and rendering verdicts against explicit pass/fail criteria.

Stop and Exit Conditions

• Release plan complete when: the plan names version, target date, milestones and branch cut, owners (RACI), scope items, risks with mitigations, rollout plan, rollback contingency, comms plan, and sign-offs.
• Readiness checklist complete when: every item in each dimension (functional, non-functional, operational, governance) has an owner and evidence, and a go/no-go decision is recorded.
• Rollback runbook complete when: trigger thresholds, impact assessment, decision criteria, per-layer rollback steps, verification SLIs, rollback ordering, comms, and a rehearsal log are all in place.
• Version bump complete when: the next version is computed from actual commit history (or an explicit file), validated against strict SemVer, and the bump rule is justified by the conventional-commit types.
• Compliance record complete when: the change chain — ticket → PR review → CI → approval → deploy log → verification — is complete, sampled, and retained per policy, with separation of duties respected.
• Bounded escalation: stop after three non-converging diagnostic passes and report the evidence collected so far.