Release Management: A Complete Guide for Teams

Release management is the set of practices that decide which changes ship together, confirm that the combined change is safe to ship, move it into each environment in a controlled order, and keep a record of what happened. It sits between the people who build changes and the people who live with them: customers, support staff and the on-call engineer who is paged when something breaks.

A release can be a numbered version of a product, a monthly drop of a web application, a hotfix for a single defect, or a coordinated change across several services. What makes it a release rather than a deployment is the decision around it. A deployment is a technical act that puts code in an environment. A release is a business act: a named group of changes, an owner, a date, a set of people who agreed, and a record. One release can involve many deployments, one per environment, and a deployment can happen without a release when a team uses feature flags or continuous delivery.

This guide describes the whole cycle in the order a team meets it. It is written for engineering leads, product managers, release coordinators and operations staff, and it is deliberately tool independent. Where it describes how Atlas supports a step, that is stated plainly, and where Atlas does not do something, that is stated too.

Why release management exists

Teams that ship rarely, or ship to customers who notice failures quickly, learn the same lessons in the same order. The first lesson is that the question "is it ready?" has no shared answer unless someone writes the answer down. One engineer thinks ready means the tests pass. A product manager thinks it means the documentation is done. Support thinks it means they have been told. Operations thinks it means a rollback has been rehearsed. Without a checklist and a named owner, each person assumes someone else has covered their concern.

The second lesson is that most release failures are not code defects. They are coordination failures: a migration nobody ran in staging, a feature announced before it was deployed, a change shipped during a customer's busiest week, a fix released with no way to undo it. Release management exists to make those failures visible before they happen, by turning implicit expectations into explicit checks.

The third lesson is that a record is worth more than memory. When something breaks on a Thursday, the first useful question is what changed. A team that can open a release and read its scope, its sign-offs and its deployments answers that in a minute. A team that cannot, reconstructs it from chat history.

The stages of a release

Different organisations use different names, but nearly every release passes through the same stages. Naming them makes it clear who is responsible at each point and what must be true before moving on.

• Planned. The release exists, has a name, an owner and a target day, and contains little or nothing yet. Its purpose at this stage is to reserve intent: someone is responsible, and others can see it coming.
• In progress. Work is under way. Scope is being assembled and the checks that must pass are being defined and worked through.
• Ready. The work is complete and the evidence is in. The release is waiting for the decision to ship, a window in which to ship, or both.
• Released. The change has gone live. From this point the release is a record: its scope and checklist should no longer change.
• On hold, cancelled, rolled back. These are the exits. A release on hold can resume. A cancelled release is finished. A rolled back release records that the change was withdrawn after it shipped, which is different from never having shipped.

Step 1: Decide the scope

Scope is the list of changes that ship together. In most teams these are tasks, tickets or pull requests. The scope should be assembled deliberately, not discovered. A useful rule is that every item in a release has a reason to be in this release rather than the next one, and that someone can state the reason.

Keep releases small enough to reason about. The risk of a release grows faster than its size, because changes interact. Two safe changes can be unsafe together if they touch the same table or the same screen. Small releases also make rollback cheaper, because withdrawing fewer changes disturbs fewer users.

Make the scope visible to people who are not engineers. Support needs to know what changed so they can answer questions. Sales and customer success need to know what is coming so they do not promise it too early or deny it too late. A scope that lives only in a repository is invisible to those people.

In Atlas, a release gathers tasks from any project in the workspace. You search for the tasks and add them, and the release shows how many are done. Tasks you are not allowed to read are not listed, and the interface reports how many are hidden, so the count remains honest. A release holds up to 2000 tasks.

Step 2: Define what ready means

Readiness is the part of release management that most teams do informally and most often regret. The remedy is to write the checks down before the work finishes, so that the definition of ready cannot drift to match the state of the work.

A good readiness list covers five areas. Quality covers testing, including regression testing and any performance or accessibility checks your product needs. Security covers review of the change, dependency checks and any data handling concerns. Documentation covers user documentation, internal runbooks and release notes. Operations covers monitoring, alerting, capacity, migrations and a rehearsed way back. Communication covers who must be told, and when, including support and affected customers.

Each check should be marked as required or optional. A required check blocks the release. An optional check is advisory. This distinction matters more than it looks. A list in which every item is mandatory trains people to tick boxes to get past them, and a list in which nothing is mandatory is a suggestion. Keep the required list short and meaningful, and keep the optional list for good practice that should not stop a hotfix.

Atlas supports a readiness checklist with exactly these categories (quality, security, documentation, operations, communication and other), each required or optional. A release holds up to 100 checks. The detailed list is in the guide to the release readiness checklist.

Step 3: Collect sign-off from the right people

Sign-off turns a private judgement into a shared, recorded decision. The people asked should be those who carry a consequence if the release goes wrong: the engineering lead for technical soundness, the product owner for scope, quality assurance for test evidence, and, for sensitive changes, security or operations.

Keep the group small. A long list of approvers diffuses responsibility and slows the release without improving it. Ask each person for a specific decision, approve or reject, with a comment that says why. A rejection with a reason is useful information. A silent delay is not.

Make it impossible to approve on someone else's behalf. In Atlas only the person who was asked can approve or reject their own sign-off. Asking the same person again resets their earlier decision to pending, so an approval given for an earlier version of the scope cannot quietly stand for a later one. Each person asked is notified, and the release owner is told how each decision came out. A single request can ask at most 20 people. The sign-off process guide covers how to choose approvers and how to handle a rejection.

Step 4: Read the readiness picture

With scope, checks and sign-offs in place, the release owner needs one view that answers two questions: how much is left, and what is stopping us. These are different questions and need different answers. A score answers the first. A list of blockers answers the second.

Atlas computes a readiness score from three inputs. Scope counts for 50 percent, required checks for 30 percent and sign-offs for 20 percent. A release with no scope scores zero. The score is a guide to how much work remains. What decides whether the release can move to Released is the list of blockers, written in plain words: no scope, scope tasks that are not done, required checks that are not done, sign-offs that are pending or rejected, or an active freeze window on Production.

A target day in the past is shown as a warning, not a blocker, because a late release is a scheduling fact, not a reason to refuse to ship.

Do not treat the score as a target to be maximised. A release at 90 percent with one rejected sign-off is not nearly ready. The blocker list, not the percentage, is what the release owner should read aloud in the go or no-go meeting.

Step 5: Respect freeze windows

A freeze window is a period in which changes to a given environment are restricted. Teams use them around year-end financial closes, major customer events, peak trading periods and holidays when staffing is thin. A freeze is a statement that the cost of a failure in that period is higher than the benefit of shipping in it.

A freeze only works if it is enforced where the decision is made. A freeze that lives in an email is forgotten by the person who joined last month. In Atlas you add a freeze window with a start, an end, the environments it covers and a reason. While one that covers Production is active, releasing to Production is refused, and every release that is still open shows the freeze as a blocker. The change freeze guide explains how to design a policy that people respect, including how to handle an emergency.

Step 6: Deploy and record each environment

Most releases move through environments in a fixed order, commonly development, staging and production. The release record should say, for each environment, what happened, when and whether it succeeded. That record answers the incident question "what changed?" and the audit question "who approved it, and when did it go live?"

Atlas records deployments and does not run your build or deploy pipeline. That is a deliberate boundary. You enter a deployment by hand, or you send it through the API from your pipeline, with its environment, status and times. A deployment is planned, in progress, succeeded, failed or rolled back. Recording a deployment does not start one. A new workspace starts with Development, Staging and Production, and a workspace may name its own environments.

The practical consequence is that your pipeline stays the source of truth for how code moves, and the release remains the source of truth for why and with whose agreement. Sending deployment events from the pipeline closes the loop without anyone typing times into a form.

Step 7: Release, and override only with a reason

When nothing blocks the release, the owner moves it to Released. Sometimes something does block it, and the business decides to ship anyway: a security fix that cannot wait for a documentation check, or a contractual date that cannot move. Release management should allow this, because a process that cannot be overridden gets bypassed entirely. But the override must be accountable.

In Atlas, only a workspace owner or administrator can release past a blocker, and they must write a reason of up to 500 characters. The reason is recorded with the release and in its activity. This keeps the exception rare, visible and attributable. Anyone else who attempts the override is refused.

Once a release is Released or Cancelled it no longer accepts changes to its scope, checklist or sign-offs. That is what makes it a trustworthy record. A released release can only be rolled back, and it cannot be deleted.

Step 8: Communicate with release notes

Release notes are the outward face of the release. They tell users what changed, tell support what to expect, and give the team a written history. Good notes are grouped, short and written for the reader rather than for the author. The guide to writing release notes goes through the structure in detail.

Atlas can draft notes from the finished scope of a release, grouped into features, fixes and other changes. You edit the text, save it and publish it inside the workspace. Saving new text withdraws an earlier publication, so what is published is always what was reviewed. You can also copy the notes as Markdown for use elsewhere. Publishing in Atlas makes the notes visible inside the workspace. It does not post them to a public changelog.

Step 9: Plan the way back

Every release should have a stated way back before it goes out. The question is not whether you expect to need it, but whether you could use it under pressure at three in the morning. A rollback plan names the trigger that causes it, the owner who decides, the steps, the way to verify success and the time within which it must be complete. The rollback plan guide provides a template.

In Atlas, a released release can be rolled back, and a deployment can be recorded as rolled back. A rolled back release can return to In progress, so the fix and the next attempt stay attached to the same history instead of starting a new, unrelated record.

Choosing a versioning scheme

A release needs a name that people can say and sort. Two schemes dominate. Semantic versioning uses three numbers, major, minor and patch, so that the number tells a consumer whether upgrading is likely to break them. Calendar versioning uses the date, so that the number tells a consumer how old the software is. Libraries and public interfaces generally suit semantic versioning. Applications that ship on a rhythm often suit calendar versioning. The comparison guide in this series lays out the trade-offs.

Atlas accepts a version in either form, for example 2.4.0 or 2026.10, and a release type of major, minor, patch or hotfix. The version is optional, because some teams name releases rather than number them.

Metrics that tell you whether the process works

Measure the process by its outcomes rather than by its activity. A small set is enough.

• Release frequency: how often you ship. A falling frequency often signals fear, and fear is often a symptom of weak rollback.
• Change failure rate: the share of releases that need a rollback, a hotfix or an incident. Define the terms before you measure, and apply the same definition each quarter.
• Time from ready to released: how long finished work waits. A long wait points to a slow approval, a crowded freeze calendar or a shortage of deployment windows.
• Override count: how often a release is shipped past a blocker. A rising count means the checks are wrong or are being ignored.
• Rollback duration: the time from the decision to roll back to the confirmed return to service. Rehearse it, because this is the number that matters during an incident.

Common mistakes

• Treating the release as an event rather than a record. The ceremony of shipping is brief. The value of the record lasts years.
• One checklist for every release. A patch to copy text and a change to the billing system do not need the same checks. Adjust the list to the risk, and keep a smaller standard list for low-risk releases.
• Sign-off by silence. If no response counts as approval, the process is theatre. Require an explicit decision.
• Editing a release after the fact. If scope can change after release, the record cannot be trusted.
• No owner. A release that belongs to everyone belongs to no one. Name one person.
• Releasing into a freeze because the date is firm. Dates are less firm than they appear. Check whether the freeze or the date can give way.

Running release management in Atlas

Atlas keeps releases next to the tasks, projects and people they involve, so the scope, the checklist and the sign-offs are one record. You can see releases as a list, as a board by status and as a calendar of target days and freeze windows. The API and the Atlas MCP server cover every action on the screen, so a pipeline or an assistant can list, create and change releases, manage scope, checks, sign-offs, deployments, notes and freeze windows, and read the calendar. A token needs the releases:read scope to read and releases:write to change, and webhook events report each change.

For which plan includes Release Management and the other modules, see the pricing page. The module documentation lists the permissions and limits in full.