ReleaseOps

WHAT IT IS ReleaseOps is the discipline of moving a finished artifact into users' hands on purpose: how versions are numbered and communicated, who approves a change, how a release is staged across environments and cohorts, how it is announced, and how it is reversed. **Not this:** ReleaseOps is not BuildOps: it begins with an artifact that already exists and owns the decision, sequencing and reversal of putting it in front of users. WHY IT EXISTS Deployment and release are different events, and conflating them is the root of a large class of outages. A team that can deploy in minutes but cannot turn a feature off without redeploying has automated the easy half. Meanwhile release communication is usually an afterthought, so support teams learn about changes from tickets and customers learn from surprises. WHEN TO USE IT Adopt it as soon as more than one team's changes travel together, when a release requires coordination across services, or when the answer to "can we turn this off?" is "we can roll back the deploy". Continuous deployment does not remove the need — it raises it, because the decisions happen faster. WHO OWNS IT The team that owns the service owns its releases. A release-management function, where one exists, owns the calendar, cross-team sequencing and the standards rather than the individual decisions. The product owner owns whether a change should be visible to users, which is why feature flags belong to product as much as to engineering. Support and customer-facing teams own being told in time to be useful. WHAT GOOD LOOKS LIKE Deploy and release are separable: code can ship dark and be enabled independently. Versions are meaningful and consistently applied. Rollout is staged — a canary or cohort sees the change before everyone does, with a defined signal for continuing or stopping. Rollback is routine, timed and recently exercised. Release notes exist for the people who need them, including internal ones. Approval is proportionate: high-risk changes get scrutiny and routine ones do not queue behind ceremony. HOW TO IMPLEMENT Separate deploy from release first, with feature flags or configuration — this single change makes most of the rest optional rather than urgent. Define and time your rollback, then rehearse it. Introduce staged rollout with an explicit promotion signal. Write down what level of approval each class of change needs, and make the routine path genuinely fast so the process is not routed around. Align the incident path with /incidentops so a bad release becomes a known procedure rather than an improvisation, and reuse the deployment safety practice in /devops. HOW TO ASSESS YOURSELF Ask how long it takes to turn off the last feature you shipped, and whether that requires a deploy. Ask when rollback was last performed and how long it took. Ask who outside engineering knows what shipped this week. Take the scored self-assessment at /assess and plan the gaps with /roadmaps.