Release management for changes that span more than one service
Group related deployments into one release with dependency ordering, approvals, a change window and a rollback plan that is written before the release starts, not during the incident.
What is Release Management?
DevOpsArk release management is the module that groups related service deployments into a single coordinated release, with dependency ordering, approvals, change windows, generated release notes and a rollback plan attached before execution.
What Release Management is for
The conditions this module removes. If none of these are familiar, you probably do not need it yet.
- A change spans four services and the coordination happens in a chat thread.
- Deployment order matters and is remembered rather than declared, so someone ships the consumer before the producer.
- Approvals are collected by asking people in a meeting and recorded nowhere durable.
- Release notes are written from memory a week later, if at all.
- The rollback plan is invented during the rollback.
A release is a named group of service versions that ship together. You declare the ordering constraints between them (the schema migration before the service that depends on it, the producer before the consumer), and release management executes them in a valid order, stopping the release if a step fails rather than continuing into an inconsistent state. Approvals are requested from the named approvers for the environments involved and recorded against the release. The change window is enforced. Release notes are generated from the commits and merged pull requests in each included service, so the note reflects what shipped rather than what someone remembered. The rollback plan (which revisions to restore, in which order, and which migrations are irreversible) is produced at planning time and is part of the release record.
What Release Management does
The 7 capabilities that make up Release Management.
Multi-service releases
Group versions of several services into one release that succeeds or stops as a unit.
Dependency ordering
Declare which steps must precede which; the release executes in a valid order and halts on failure.
Approval workflow
Named approvers per environment, requested and recorded against the release rather than gathered informally.
Change windows and freezes
Enforce deployment windows and freeze periods, with break-glass recorded rather than untracked.
Generated release notes
Notes assembled from the commits and merged pull requests in every included service.
Rollback plan up front
Target revisions, execution order and irreversible steps identified at planning time and stored with the release.
Release calendar
One view of what is scheduled, what is in flight and what shipped, across teams.
How Release Management fits together
Outcomes
- Cross-service changes ship in a valid order because the order is declared, not remembered.
- Approvals are auditable without anyone reconstructing a chat thread.
- Release notes exist for every release and are accurate.
- Rollback is a prepared plan rather than an improvisation.
- Change windows and freezes are enforced by the platform.
Using Release Management, step by step
The path from connecting a source to getting value, in the order it happens.
- 1Create the release
Name it and add the service versions that ship together.
- 2Declare ordering
Set the constraints between steps, including migrations.
- 3Collect approvals
Named approvers per environment sign off; the record is kept with the release.
- 4Plan rollback
Target revisions and irreversible steps are identified before execution.
- 5Execute in window
Steps run in a valid order inside the permitted change window.
- 6Publish notes
Release notes are generated from the included changes and attached to the record.
Where teams apply Release Management
Coordinate a change across teams
Ship a schema migration, a producer and two consumers as one release with declared ordering.
Produce an auditable change record
Show the approvals, the window, the contents and the outcome for any release on request.
See what is shipping this week
Use the release calendar instead of asking each team.
Roll back a coordinated release
Execute the plan that was written at planning time, including which steps cannot be reversed.
What Release Management works with
Named integrations link to their own page. The rest are supported runtimes and formats.
Release Management: frequently asked questions
The 7 questions teams ask most often before adopting Release Management.
Release management is the practice of coordinating related changes so they reach production together, in a valid order, with the approvals, timing and rollback plan agreed in advance. It matters most when a single change spans several services.
Continuous delivery moves one artifact into one environment safely. That is ArkCD. Release management coordinates several of those deployments into one unit with ordering, approvals and a shared rollback plan.
Yes. Migrations are steps with ordering constraints like any other, and irreversible migrations are marked as such in the rollback plan so nobody assumes a clean revert is available.
From the commits and merged pull requests included in each service version in the release, grouped by service. The note reflects what actually shipped rather than what was recalled afterwards.
The release halts rather than continuing into a partially applied state. The steps already completed, the failure and the prepared rollback plan are shown together so the decision to revert or fix forward is made with full information.
Yes. Freeze periods and change windows are enforced at execution. A deployment during a freeze requires explicit break-glass, which is recorded with its justification and approver.
Releases can reference change tickets and post their status back, so the ticket reflects reality without someone updating it by hand.
See Release Management against your own environment
A 30-minute walkthrough with a platform engineer, not a sales deck. Bring a cluster and a problem.