Release management process for teams that ship often
7 min read
A release management process is the set of steps that takes a change from “merged” to “running in production and explained to the people it affects”. For a team that ships often, it comes down to seven steps: plan the scope, isolate the change, build and test, approve, deploy and verify, communicate, and review. Each step needs one named owner and one exit criterion, or it quietly stops happening.
This guide assumes a team of 5 to 50 engineers who deploy weekly or daily and want the process to stay out of the way.
| Step | Owner | Exit criteria |
|---|---|---|
| 1. Plan the scope | Product or tech lead | The list of changes in this release is written down, and anything risky is marked |
| 2. Branch or flag | The engineer who owns the change | Work is on a short-lived branch or behind a flag, so main stays releasable |
| 3. Build and test | CI, with the author on call for failures | Pipeline green on the exact commit that will ship |
| 4. Approve | Reviewer, plus release manager for risky changes | Review done, rollback path named, go or no-go recorded |
| 5. Deploy and verify | Release manager or on-call engineer | Deployed, smoke checks pass, error rate and latency match the pre-release baseline |
| 6. Communicate | Whoever understands the change, edited by someone who does not | Release notes published where users read them, support and sales told |
| 7. Review | Release manager | Metrics read, anything that went wrong has an owner and a fix |
What is the release management process?
It is the repeatable path a change follows to reach users: scope, build, test, approve, deploy, verify, announce, and look back. The point of writing it down is that every release follows the same path, so a person on holiday, a new hire or an on-call engineer at 2am can run it without asking anyone how it works.
What are the different types of release management?
There are three practical types: continuous deployment, scheduled releases and regulated change management. They differ in how much happens before a release and how much is automated. Continuous deployment ships every merged change, scheduled releases batch changes into a train, and regulated change management adds formal approval and an audit trail.
| Continuous deployment | Scheduled releases | Regulated or ITIL change management | |
|---|---|---|---|
| Release unit | One merged pull request | A batch, weekly or fortnightly | A change request |
| Scope step | Implicit, the merge is the scope | Release planning meeting | Change record with risk rating |
| Approval | Code review plus automated checks | Release manager signs off the batch | Change advisory board or delegated approver |
| Risk control | Feature flags, canaries, fast rollback | Staging soak, release candidate | Documented backout plan, maintenance window |
| Typical cadence | Many per day | Weekly to monthly | Set by the change calendar |
| Weak spot | Nobody tells users what changed | Big batches hide the change that broke things | Process time dwarfs the change itself |
Most teams are a mix. A SaaS product may deploy continuously while its mobile app goes out on a weekly train, and the one payments service that auditors care about follows a formal change record. Pick the type per service, not per company. Where changes are only exposed gradually, the release and the announcement become separate events, which is the case covered in feature flag release notes.
What are the responsibilities of a release manager?
A release manager owns the path a change takes to production. They keep the release calendar, decide whether a change is ready, run or supervise the deploy, make the rollback call, make sure users are told, and run the review afterwards.
Before the release, they confirm scope and check that every risky change has a rollback path. During it, they run the deploy checklist, watch the first minutes of production metrics and call a rollback early. Afterwards they confirm the notes went out and record what to fix in the process.
On a small team, rotate the role weekly and write the checklist so nobody needs tribal knowledge. A monorepo with many independently released packages usually needs one release owner per package, or the role turns into a bottleneck.
What are the key KPIs for release management?
Track the DORA software delivery metrics, and add one of your own: how long it takes users to be told. DORA’s research identifies five metrics, split into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate).
DORA’s guide defines them in plain terms (dora.dev, software delivery metrics):
| KPI | What it measures | What to watch for |
|---|---|---|
| Change lead time | Time from commit in version control to deployed in production | A rising number usually means queues in review or approval |
| Deployment frequency | How often you deploy, or the time between deployments | Falling frequency means batches are growing |
| Failed deployment recovery time | Time to recover from a deployment that needs immediate intervention | Rollback and alerting problems show up here |
| Change fail rate | Share of deployments that need a rollback or hotfix | Rises when batches are too big or testing is thin |
| Deployment rework rate | Share of deployments that are unplanned and caused by a production incident | A sign that fixes are shipping faster than lessons |
| Time until users are told | Minutes from production deploy to a published, user-facing note | Measure it yourself, no framework supplies it |
Older material lists four keys and calls recovery “time to restore”. The current guide uses the five above.
The same guide warns against treating these as targets. Setting a goal such as “everything deploys several times a day by year end” invites teams to game the numbers, and the metrics are meant to be read per application or service, not blended across the company. Its practical advice for improving all of them is to shrink the size of each change, because smaller changes are easier to review, move through the pipeline and recover from.
How does release communication fit into the release management process?
It is step six, and it has an owner and an exit criterion like every other step: notes published where users read them, and internal teams told. Teams skip it most often, because deployment tooling reports success the moment code is live.
The cheapest way to keep this step on schedule is to write the entry when the change merges, not when the release ships. The pull request already holds the title, the author, the linked issue and the context. A draft built from it gets edited, not written from memory a week later. That is the idea behind changelog automation: derive a draft on merge, hold it for a human to approve, then publish it everywhere from one source. Changeloop works this way, drafting entries from merged pull requests with AI and holding them for approval before anything is published.
Two variations are worth planning for in advance. Support and sales need a different note from customers, which is what internal release notes are for. An incident-driven release has no time for the normal drafting loop, so keep a short template ready, as described in emergency release notes. The release notes template gives you a starting shape for the customer-facing version.
How do you keep the process light?
Automate every exit criterion a machine can check, and keep humans for the judgement calls. A green pipeline, a deploy marker on the dashboards and a draft changelog entry per merged pull request are checkable. Whether a rollback plan is credible, or the notes make sense to a customer, takes a person.
To test the process, pick a release from last month and ask whether someone outside the team could tell, from the written record alone, what shipped, who approved it, how it was verified and when users were told. Any gap is your next improvement.
FAQ
What is the difference between release management and change management? Release management gets a set of changes built, tested, deployed and announced. Change management, in the ITIL sense, is the approval and risk process around each change. Teams that ship often fold approval into code review and automated checks.
How often should we release? As often as your tests and rollback path allow, which for many web teams is daily or more. DORA’s guidance is to reduce the size of each change, since small changes are easier to review and recover from.
Do small teams need a release manager? They need the responsibilities but not necessarily the title. Rotate the role between engineers, give the person on rotation a written checklist, and make sure someone owns each of the seven steps.
What should a release checklist include? Scope confirmed, pipeline green on the shipping commit, rollback path named, approval recorded, smoke checks after deploy, metrics compared with the baseline, release notes published, support told, and a review scheduled. Keep it to one page.
The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.