Most web agencies and CMS shops already deploy several times a week. Far fewer can answer, in one sentence, what happens between “the build is on the server” and “visitors can see the new behaviour” — and that gap is where every painful launch lives. ReleaseOps is the label for the discipline that manages exactly that gap, and the twelve checks below audit whether your team actually has one. Score honestly: a check only passes if it happened within the last quarter, not if it would happen in theory.

Why ReleaseOps Matters More on the Web

Two reasons. First, on a website the risky change is often not the code at all. Theme settings, menu structures, content models, redirect tables, pricing rows — all of it changes what visitors experience, and none of it waits for a build. Second, the industry keeps supplying expensive proof. In 2024, a security vendor shipped a content-configuration update whose field count did not match what the running code expected; machines crashed fleet-wide, and the change had never been staged or validated like software. If a configuration file can take down computers around the world, a rushed settings import on a production CMS deserves the same caution you give a code deploy.

The audit below groups the checks into four areas: separation, exposure, recovery and governance. Twelve items sounds like a lot, but most teams can score themselves in half an hour with a shared document and no tooling changes.

The ReleaseOps Audit: Twelve Checks

Separation

1. Two verbs, two events. The team states plainly that installing a version and exposing it to visitors are separate acts, and runbooks never use the words interchangeably.
2. A silent path exists. At least one significant change in the past quarter went live dark — installed and invisible — before anyone deliberately switched it on.
3. Content and config ride the same rails. Settings imports, template edits and policy changes pass through review and a staging environment rather than straight into the live database.

Exposure

4. Small audiences first. Big behaviour changes reach a limited group — internal staff, a slice of sessions, one locale — before they reach the full audience.
5. The test is sized, not symbolic. When a small slice of traffic tries the change, someone has confirmed it would actually register the kind of failure you fear; a brief glance on a low-traffic page proves nothing either way.
6. Widening has soak time. Each stage waits a defined period before the next, and the wait survives deadline pressure.
7. Toggles carry expiry dates. Every feature switch is registered with an owner and a removal date, and switches living past a few weeks get challenged.

Recovery

8. The undo is rehearsed. Within living memory the team has rolled a change back on purpose, on a good day, and recorded how long it took.
9. Data changes have a both-versions plan. Schema or content-model work keeps old and new software functional against the same data — extend first, migrate, contract later — so an undo never strands the database.
10. Anyone on support can pull the lever. The person nearest the incident can turn a change off without hunting for approvals, because that authority was granted in advance and in writing.

Governance

11. Gates declare their effect. Each approval point states whether it blocks, pauses or records, and every override carries a name and an end date.
12. The numbers exist. Someone can quote, roughly, how much visitor exposure a bad release cost last quarter and how often a staged test caught a defect before wide launch.

The Failures the Audit Keeps Catching

Run this against enough web teams and the same three stories appear again and again. The midnight settings import: someone “just quickly” fixed a pricing table in production, the change was technically a release, and it appeared in nobody’s changelog — check three exists to make that path impossible. The eternal toggle: a feature switch flipped on for a client two years ago is now load-bearing, everyone is frightened of it, and nobody remembers the code path without it — check seven’s expiry dates exist to stop that archaeology project before it starts. The theoretical rollback: the runbook says “revert the release”, the button has never been pressed outside an incident, and the one time it mattered the database schema had already moved on — check nine’s both-versions plan is the only real defence.

Notice what the stories share: none of them are code bugs. They are gaps between installing and exposing, which is precisely the territory this audit patrols. That is also why passing the audit feels uneventful — the reward is that nothing happens, repeatedly.

Scoring Without Self-Deception

Count the passes. Nine or better and launch nights are already boring — protect that with a quarterly rhythm. Five to eight means the machinery exists but has known, negotiated gaps; pick the two cheapest fails and close them this month. Below five, the honest read is that launches are still gambles, and the first investments should be checks one, eight and eleven: separate the vocabulary, rehearse the undo, and make every gate state its terms. One caution while you fix things: resist the reflex to freeze everything during busy seasons. A blanket stop feels safe and usually just moves risk around; if you need breathing room, scope it tightly to the risky category of change and give it an end date.

Teams mapping the wider journey can slot this audit into a practical DevOps, SRE and platform roadmap instead of treating it as a standalone ritual. The two complement each other: the roadmap decides where the team is going, the audit checks whether the shipping layer can survive the trip.

Making the Audit a Habit, Not a Document

Value comes from rhythm, not from the first pass. Attach the twelve checks to quarterly planning, rotate who scores them so answers stay honest, and publish the results next to deployment statistics so the trend is impossible to ignore. When a check fails twice in a row, promote it to a standing agenda item until it stops failing.

Pair the practice with the site-side discipline in this step-by-step CMS development checklist, which covers the build-stage questions the audit assumes you already ask, and revisit the recurring failure patterns in common CMS website mistakes — several of them are audit failures wearing older names. For the reasoning behind every item, the ReleaseOps reference at The Ops Atlas explains the full machinery, from canary sizing to freeze policy, in more depth than any single checklist can carry.