Release management is the practice of getting a change from committed to safely in production, coordinating the order, the approvals, the timing and the risk. A release intelligence layer joins those signals up rather than adding another tool to run them.
Release management is the practice of planning, coordinating and controlling how software changes move from committed code to production: deciding what ships, in what order, with whose approval and inside which time window, and keeping the record to show it happened that way. It spans the work in a tracker, the code in source control, the pipeline that builds and deploys it, and the incident tool that tells you when it broke.
Whatever the tooling, release management is the work of answering the same questions before each release, and being able to prove the answers afterwards.
Jira knows the work. GitHub knows the code. Jenkins knows the build. PagerDuty knows it broke. None of them knows the release, so the answers get assembled by hand, at speed, usually at night. A release intelligence and governance layer sits above these tools and joins their signals into a dependency graph, an audit trail, and a verdict on whether to ship.
Decide what goes in the release and what it depends on. Dependencies found here are cheap; found at deploy time they are not.
The change is built and tested. Test evidence is a release input, whether or not anyone writes it down.
The named owners sign off, or the release is blocked until they do. The approval is recorded where it can be found again.
The pipeline ships it inside an open window, using whichever strategy the team has chosen (rolling, blue-green, canary or behind a feature flag).
Monitors and alerts are read against the deployment. A failure is traced to the change that caused it.
What failed, what nearly failed and what the checks missed becomes the next release's checklist.
CI/CD builds, tests and deploys. A release layer does not build or deploy anything: it has no runners and no plugin in the pipeline. It reads the deployment events your CI already emits, and adds the layer above them.
IT change management (the ITIL discipline, usually run through a change advisory board and a system such as ServiceNow) governs change across the organisation, including infrastructure and configuration. Release management is narrower and closer to the code: it coordinates the content, order and readiness of software releases, and feeds the change record with evidence.
Scope, sequencing, approvals, timing, risk assessment, verification and rollback planning, and a record of the decision. Teams differ in how formal each step is, but each one exists, even when it only lives in someone's head or a Slack thread.
Change management is the organisation-wide discipline for approving and recording changes of every kind, often with a change advisory board. Release management coordinates the software releases themselves: what is in them, the order they ship in and whether they are ready. In practice release management supplies the evidence that change management asks for.
No. CI/CD is the automation that builds and ships code. DevOps is a way of working that shortens the path between writing code and running it. Release management is the coordination and decision layer around both: it does not replace the pipeline, it decides and records what goes through it.
Yes, though it looks different. The questions (is it safe, is it in the right order, who approved it, can we prove it) do not disappear when deploys get small and frequent. They get answered by automated checks and recorded evidence instead of a weekly meeting.
The DORA four keys are the usual measure: deployment frequency and lead time for throughput, change failure rate and time to restore for stability. Beyond those, ask whether you can show, for any release, who approved it and on what evidence.
Both exist. The release manager is the person accountable for the outcome; release tooling is whatever helps them see the whole release. ArcRelease is a layer for that seat: it reads the tools your teams already use and is never in the deploy path.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days