A Release groups several changes together into one coordinated rollout — the difference between deploying ten related changes one at a time and shipping them as a single, tracked event with its own approval, staged rollout, and post-deployment monitoring.
Lifecycle
A release moves from draft through scheduling, review, approval, deployment, and closure, with cancellation available from any point before deployment starts and a dedicated rollback path if it goes wrong after.
Bundling changes and staging the rollout
Add or remove individual changes from a release as it's being planned. For anything beyond a single-environment deploy, define the environments it needs to move through in order — staging then production, for example — and advance each stage only once it's been verified, with sign-off notes attached at each step.
Go/no-go approval
Designated approvers vote go or no-go on a release before it deploys. A single no-go cancels it outright; once every approver has voted go, it advances to approved automatically — the same idea as CAB voting on an individual change, applied at the release level.
Freeze windows
Freeze windows — named, environment-scoped periods like a holiday code freeze — are defined here, on the Releases page. They're what an individual Change's scheduling actually checks against: a normal change can't be scheduled into a freeze window, only an emergency change can bypass one.
After deployment
A high- or critical-risk release automatically opens an Early Life Support window after it deploys — a focused monitoring period that watches for incidents correlated back to the release. If trouble crosses a threshold during that window, PulseServe recommends a rollback rather than triggering one automatically, so a human still makes the call. When the window closes, a Post-Implementation Review opens automatically for high/critical-risk releases, so the retro is never something someone has to remember to schedule.
AI assistance
A release can have an AI-generated risk assessment computed automatically on submission (or on demand) — weighing the bundled changes' risk levels, what they touch in the CMDB, and how the org's releases have historically gone — plus one-click AI-drafted release notes summarizing what's in it.
Example
A team bundles six changes — three backend services, two config updates, one database migration — into a single Friday release. The AI risk assessment flags the database migration as the main concern given its blast radius. Two designated approvers vote go; the release deploys to staging first, gets signed off, then advances to production. Because it's flagged high-risk, an Early Life Support window opens automatically for the next 24 hours, watching for correlated incidents before the release is considered fully settled.