Release Trains & Change Management

Deployment strategies answers a mechanical question: how does one build move from "built" to "serving live traffic" without an outage. This page sits one level above that: who decided this bundle of changes was allowed to ship at all, what number does it ship as, what record survives that decision, and what happened to the change control a smaller, slower shop used to get from a room full of people reviewing every release by hand. We'll cover release trains — the fixed-cadence alternative to "ship whenever a feature happens to be done" — how a coordinated release earns a version number and a changelog entry above the level of any single service's build, and exactly what replaced the Change Advisory Board once deploys stopped being rare enough for a weekly meeting to review them one at a time.

Deploy vs. release: the coordination layer above one pipeline run

☺ Like you're 10: Deploying puts new code on a server. Releasing decides that a bundle of changes — sometimes from many different services — is the official thing people see next, and somebody has to coordinate that second decision across more than one pipeline.

A deploy is what CI/CD pipelines already covers in full: one pipeline run moves one artifact from "built" to "running." A release is a different, higher-altitude event — a named, versioned bundle of changes, sometimes from a single service and sometimes stitched together from dozens, that an organization is willing to stand behind and communicate about. In a single-service shop deploying continuously, the two can be nearly the same moment, and CI/CD pipelines already showed you the mechanism that decouples them even there — the when: manual gate that turns continuous delivery into continuous deployment, and the feature flag that keeps deployed code invisible until someone decides to release it.

The coordination problem shows up the moment a product is made of more than one independently-deployable piece, or has a stakeholder outside engineering who needs a stable cadence to plan around — an enterprise customer with their own change-management calendar, an app-store review queue, a regulator, a firmware fleet that only accepts one update a quarter. At that point, no single service's pipeline can answer the questions that actually matter: which combination of service versions constitutes "the March release"? What changed, in language a customer or a support team can use? Who is accountable for the claim that this combination is safe together, not just that each piece individually passed its own tests? Answering those three questions — when, what, and who signed off — is what the rest of this page is about, and each has a mechanism: release trains answer when, versioning and changelogs answer what, and the shift from a Change Advisory Board to policy-as-code answers who signed off, and how that sign-off actually happens at deploy speed instead of meeting speed.

Release trains: departing on schedule, not on completeness

☺ Like you're 10: A train leaves at a fixed time no matter who's still tying their shoes — so instead of the calendar bending around one feature, the feature waits for the next train.

A release train ships on a fixed calendar cadence — weekly, every four weeks, every six weeks, twice a year — and any given piece of work ships in whichever train's cutoff it makes. Missing a cutoff doesn't cancel the work; it just waits for the next departure. This is the deliberate opposite of the pure continuous-deployment model CI/CD pipelines describes, where each merge deploys the moment it clears the pipeline with nothing to wait for. A train model makes one specific trade: it fixes the calendar and lets scope vary release to release, instead of fixing scope ("this feature ships when it's done") and letting the calendar vary unpredictably.

The pattern is not a DevOps invention — it predates the term, and some of the clearest real examples run some of the biggest release surfaces on earth:

• Chrome ships on a fixed major-version cadence — roughly every four weeks as of this writing, down from six weeks before 2021 — moving a build through Canary, Dev, Beta, and Stable channels with a hard branch-cutoff date each cycle. Chromium's own release-process documentation calls this "the train model" explicitly: a feature that isn't ready by the branch point simply rides the next train, no exceptions granted for being close. (Check Chromium's current release-process docs for the exact cadence in effect — it has changed before and can change again.)
• Rust runs a strict six-week train with three channels: nightly builds every day off the tip of the main branch, promoted to beta every six weeks, promoted to stable six weeks after that. New, not-yet-stable language or standard-library features live behind a #![feature(x)] gate that only works on nightly; a feature not stabilized in time for a given cycle isn't in that release — it stays gated and waits for a future stabilization to land.
• Ubuntu ships every six months, in April and October, with a Long Term Support (LTS) release every two years carrying a much longer support commitment. The version number is the departure date — 24.04, 24.10 — which previews the versioning question the next section digs into.
• SAFe's Agile Release Train (ART) applies the same idea at the organizational level: a long-lived "team of teams," commonly on the order of five to a dozen teams, plans and commits together and demonstrates an integrated increment on a fixed cycle called a Program Increment (PI) — commonly quoted as roughly eight to twelve weeks, though the exact structure varies by SAFe version, so verify current numbers against Scaled Agile's own framework materials rather than treating this page as the source of truth on SAFe specifics. The train departing here means the whole team-of-teams demos an integrated increment together, not that each team ships independently on its own private clock.

What actually happens at the cutoff: branches, freezes, and the features that miss the train

☺ Like you're 10: Pack your suitcase and zip it shut before the whistle blows, and you can decide to open it whenever you want later — even after the train's already left the station.

Mechanically, a cutoff is a moment, and it's usually enforced by cutting a branch. At the cutoff date, a release branch — often literally named release/24.3 — is cut from trunk at whatever commit is current; work still merging to trunk after that moment keeps moving toward the next cutoff instead. After the cut, the release branch typically accepts only narrow, reviewed cherry-picks — a fix for a bug found during stabilization, not new work — while trunk keeps evolving underneath it. This "stabilization branch" pattern is the literal mechanism behind every one of the real-world trains above, and it's the same trunk the rest of this course assumes you're doing trunk-based development on in the first place.

Two techniques keep a team from experiencing the train as a hard on/off switch on every feature:

Feature flags let code merge to trunk — and board any train, even one it isn't conceptually finished for — while staying invisible to users, exactly as feature flags & progressive delivery and version control & branching describe. This is the suitcase metaphor made literal: the code physically ships on the train it happened to be ready to board, packed and zipped shut, and gets "opened" — released to users — on a completely separate schedule, whenever someone actually flips the flag. Boarding a train and being released to users become two different decisions, made by two different people, on two different clocks.

Cutoff freezes are the second technique, and they're the first piece of change control this page will later show getting automated: after the branch cut, the release branch enters a freeze where only pre-approved, narrowly-scoped changes — usually bug fixes discovered during stabilization testing — are allowed in at all. This "code freeze" is itself a governance policy with a name, a start date, and an end date, which is exactly the shape of thing a policy engine can enforce later in this page instead of a person remembering to say no.

Naming what shipped: SemVer, CalVer, and versioning above a single service

☺ Like you're 10: One number on a box can mean "is it safe to open this next to what I already have," or it can just mean "when was this box packed" — those are two different questions, and you have to pick which one your number is answering.

Build & artifact management already covers the core rules of Semantic Versioning precisely — MAJOR bumps on a breaking change, MINOR on backward-compatible new functionality, PATCH on a backward-compatible fix, with pre-release and build-metadata suffixes for the rest — so this page won't re-derive that spec. What it doesn't cover is the question a release train forces you to answer: once a release is a coordinated bundle of many independently-built services, whose SemVer number, if anyone's, describes the release itself?

Two real, named strategies answer this differently, and monorepo tooling supports both directly:

• Independent versioning — every service keeps its own SemVer (checkout-service 4.2.0, billing-service 2.11.3), and "the release" is a snapshot manifest of which versions were deployed together, not a single number that means anything on its own. This is the natural extension of build once, promote everywhere and the "immutable, signed release manifest" the DevOps lifecycle describes at the Release stage — the manifest, not a version number, is the unit of truth.
• Synchronized (fixed) versioning — the whole train ships under one version, and every constituent package is bumped to match whether or not it individually changed. It's simpler for an external customer or a support engineer to talk about ("we're running 24.3, upgrade to 24.4") at the direct cost of a version bump on a component that genuinely didn't change. JavaScript monorepo tooling names this choice explicitly: Lerna's fixed mode and the Changesets tool both implement synchronized versioning as one first-class option, with independent mode as the other.

There's no universally correct pick — it's the same trade the cadence decision already made. Fixed versioning buys one clean external story; independent versioning is more honest per-component but forces every consumer to track a compatibility matrix instead of one number.

CalVer (calver.org) is the scheme that makes the cadence itself the version: YYYY.MM or YY.MM[.DD], directly encoding when something shipped rather than what changed inside it. Ubuntu's 24.04 / 24.10 from the previous section is exactly this. The two schemes are answering genuinely different questions: SemVer's number is a claim about compatibility — is it safe to upgrade without reading anything — while CalVer's number is a claim about recency — how old is what I'm running, and how long until it ages out of support. CalVer only really fits a release that already runs on a coordinated, meaningful cadence; SemVer fits a component consumed as a dependency that has to make a compatibility promise entirely on its own, independent of any calendar. Worth noting explicitly: unlike SemVer, which is one ratified specification at semver.org, CalVer is a family of per-project conventions that agree "the version encodes a date" and disagree on almost everything else — check calver.org's own comparison table before assuming any two CalVer projects format their number the same way.

The changelog: the record a release actually needs

☺ Like you're 10: A "what's new" list pinned by the door means nobody has to open every box to find out what changed — but the list for the movers has to look different from the list you hand a guest.

Two documents both get called "the changelog," and treating them as one file is a real, common mistake. The first is the generated, engineering-facing log: exactly what semantic-release, release-please, or git-cliff already produce automatically from Conventional Commits, as version control & branching describes — one line per commit, sorted by type, genuinely useful mid-debugging session when you need to know everything that changed since v4.1.0. The second is the curated, audience-facing release note: a human-edited document written for someone who doesn't care that eslint got bumped to 8.57 in between the two features they actually care about.

Keep a Changelog (Olivier Lacan) formalizes the second document with a specific structure: newest release at the top, each version dated, entries grouped under Added, Changed, Deprecated, Removed, Fixed, and Security, with an Unreleased section at the very top that engineers add a line to as they merge — so writing the note for a release isn't a scramble the night before it ships. The project's own guiding principle is worth stating directly, because it's the entire reason the two documents shouldn't be the same file: changelogs are for humans, not machines.

## [Unreleased]
### Added
- Retry with exponential backoff on payment gateway timeouts (#482)

## [24.3.0] - 2026-08-11
### Added
- Dark-launch pricing engine, behind the `pricing-v2` flag (off by default)
### Changed
- Checkout session timeout raised from 15m to 30m (#471)
### Fixed
- Order totals rounding error on split-tender payments (#455)
### Security
- Rotated the payments-service database credential (see #497)

At release-train scale, the curated changelog is also Ellie's "record" — the same document that answers "what actually shipped in 24.3" during a postmortem six months later, and, extended one step further, becomes the evidence a compliance-driven change process needs that a change was reviewed and communicated, not merely deployed. A schema migration deserves its own careful changelog entry more than almost anything else in a release, precisely because it usually can't be rolled back the way an application deploy can — database change management covers that specific, harder case in full.

What a Change Advisory Board actually did, and why it stopped scaling

☺ Like you're 10: One guard checking every ticket by hand works fine for twelve passengers a day. It stops working the moment four hundred people show up in an hour — not because the guard got careless, but because there's only one guard.

The term comes from ITIL, and it's worth using precisely rather than as a generic synonym for "slow approval process." ITIL's change management practice — renamed change enablement in ITIL 4 — defines three change types. A standard change is pre-authorized, low-risk, and follows a known, repeatable procedure — it doesn't need case-by-case review at all, because the review already happened once, when the procedure itself was approved. A normal change requires individual assessment and authorization — this is what a CAB exists to evaluate. An emergency change needs to happen immediately, usually to fix an active incident, and is reviewed by an expedited Emergency CAB (ECAB) rather than waiting for the normal cycle. A Change Advisory Board, concretely, is a standing group — IT operations, security, sometimes business stakeholders — that meets on a fixed cadence, commonly weekly, to review a batch of proposed normal changes: what's changing, its blast radius, whether a rollback plan exists, whether it conflicts on the calendar with anything else, and votes to approve, reject, or send it back for more information.

What-is-devops.html's wall of confusion already named where this comes from structurally: Ops, carrying all the operational risk of a change it didn't write and doesn't trust, adds friction as a defense — "change advisory boards, freeze windows, manual sign-off gates" is the exact phrase used there. A CAB isn't an arbitrary bureaucratic tax; it's a rational response to a genuine incentive misalignment, invented before "you build it, you run it" was the norm.

It breaks down at DevOps deploy frequency for a mechanical reason, not just a cultural one: a weekly meeting has a fixed number of review-hours in it. Multiply weekly deploys by the orders of magnitude the DORA metrics describe for elite performers — on-demand, multiple deploys per day, per service — and the board physically cannot read every diff. It has exactly two ways to cope, and both are bad: it becomes a rubber stamp that approves without meaningfully evaluating anything, which is governance theater rather than governance, or it becomes a genuine bottleneck that forces many changes to batch into one weekly review slot, which increases the blast radius of each approved change and directly works against the change-failure-rate metric the board exists to protect.

Continuous delivery's answer: governance re-expressed as policy-as-code

☺ Like you're 10: Turnstiles replace the guard, not the ticket check — they run all day instead of once a week, and they keep their own log of every single person who walked through.

Here's the correction worth stating plainly, because it's the single most common misreading of what continuous delivery actually did to change control: CD did not delete the review a CAB used to provide. It moved the same judgment calls into automated, machine-enforced policy that runs on every change instead of a sampled batch once a week. Walk the CAB's own questions across to their real automated equivalents, and the mapping is close to one-to-one.

"Is this a low-risk, well-understood, repeatable change?" is ITIL's own standard change concept, and it's now literally encoded rather than merely pre-approved on paper: a policy rule auto-approves anything matching a defined, narrow shape — a dependency patch bump that passes every gate and touches no file under a sensitive path, say. Open Policy Agent (OPA) and its Rego policy language, Conftest (built on OPA specifically to test structured config and IaC files against Rego rules inside a pipeline stage), and HashiCorp Sentinel — embedded directly in Terraform Cloud/Enterprise, Vault, and Consul, with graduated enforcement levels of advisory, soft-mandatory, and hard-mandatory — are the real tools doing this work today.

# A Rego policy for Conftest: auto-approve a "standard change" —
# a patch-only dependency bump that touches nothing sensitive.
package release.standard_change

default is_standard = false

is_standard {
    input.change_type == "dependency_patch"
    not touches_sensitive_path
    input.tests_passed == true
}

touches_sensitive_path {
    some f
    input.files_changed[f]
    startswith(input.files_changed[f], "infra/iam/")
}

deny[msg] {
    not is_standard
    msg := "not a pre-authorized standard change — route to required review"
}

"Who needs to sign off, specifically?" becomes CODEOWNERS plus branch protection: a required-reviewer rule scoped to exactly the files that matter, so only the security team is a required reviewer on a change touching an IAM policy file, replacing a blanket weekly review of everything with a targeted one that only triggers when it's actually relevant.

# .github/CODEOWNERS — replaces "the CAB reviews everything"
# with "the right reviewer is required only where it matters"
infra/iam/**           @platform-security-team
db/migrations/**        @data-platform-team
*                        @release-managers   # fallback: everything else

"Is this scheduled sensibly — are we inside a freeze window?" becomes a freeze-window check running as code: a pipeline stage or bot reading a versioned freeze calendar and blocking merges or deploys automatically during a defined window — a holiday code freeze, a known high-traffic event — instead of relying on a human to remember to say no in a meeting. And "is there a rollback plan?" is where deployment strategies' actual mechanics do the work a CAB used to only ask about on paper: a canary or blue-green rollout with an automatic rollback on a failed health check is a verified rollback plan, proven continuously on every release, not a checkbox someone attested to once in a change-request form.

And "what's the audit trail?" — every one of the checks above runs as code and logs a timestamped, git-SHA-linked, pass-or-fail result automatically, every single time. That's a more complete and more honestly verifiable audit trail than a CAB meeting's minutes, which record only that a meeting happened and a vote was taken — not that anyone meaningfully evaluated the diff in front of them. The deeper treatment of policy-as-code as its own discipline, including how this evidence trail feeds an actual compliance audit, lives in compliance as code & policy enforcement; the security-specific half of this same shift-left move is in shift-left security for DevOps.

Policy-as-code is excellent at exactly the thing a standard change already is: a shape of risk someone has already thought through and written a rule for. It is structurally weak at genuinely novel risk nobody has written a rule for yet — which is precisely why a real, named emergency-change path still exists in a mature CD organization: a deliberate, expedited, human-in-the-loop escape hatch for the one change nobody anticipated, not a quiet return to reviewing everything by hand. Coordinating this whole model across dozens of teams at once — not just one release train, but many trains and many policy scopes running in parallel — is its own problem, covered in scaling CI/CD across teams.