Home/Glossary
Glossary

The terms, defined plainly.

Short, plain definitions of the release management concepts ArcRelease is built on, each with its own link and, where there is one, a fuller guide.

Release management, from A to Z.

Audit trail
A chronological record of who did what and when, kept so a decision can be reconstructed later. For releases it should be written at the moment of the decision and be append-only, so it cannot be edited or deleted afterwards. Read more →
Blast radius
The set of services a change could plausibly affect if it fails. It is used to decide which deployments could have caused an alert, and how far a failure could reach. Read more →
Blue-green deployment
A deployment strategy that runs two production environments, one live and one idle. The new version goes to the idle one, traffic is switched across when it checks out, and switching back is the rollback.
Canary release
A deployment strategy that sends a new version to a small share of traffic first and widens the rollout only if the signals stay healthy, limiting the impact of a bad release.
Change advisory board (CAB)
A group that reviews and approves significant changes in an IT change-management process, usually assessing risk, timing and rollback. Many regulated organisations require one.
Change failure rate
The percentage of production deployments that cause a failure needing remediation, such as a hotfix or a rollback. One of the four DORA keys. Read more →
Change freeze
A period during which changes to production are restricted or stopped, usually around a high-risk moment such as a holiday peak or an audit. Also called a code freeze or deployment freeze. Read more →
Deployment frequency
How often a service is deployed to production. One of the four DORA keys, and a measure of throughput. Read more →
DORA metrics
Four measures of software delivery performance from the DevOps Research and Assessment programme: deployment frequency, lead time for changes, change failure rate and time to restore service. Read more →
Emergency change
A change that ships outside the normal flow because waiting would cost more, such as a fix for a live outage. It is normally allowed with a named approver and reviewed afterwards. Read more →
Evidence
The recorded facts a decision rests on: a test result, an approval, a deployment event, a scan. In ArcRelease a check with no evidence is reported as "not checked", never as a pass. Read more →
Feature flag
A switch in the code that turns a feature on or off without a new deployment. Flags let a change ship dark and be enabled gradually, and give a fast way to switch it off.
Go/no-go decision
The checkpoint before a release ships where a named person or group decides whether it goes ahead, goes on a stated condition, or does not. Read more →
Hard dependency
A dependency that blocks a release: it should not ship until the upstream release or change it needs has shipped. Read more →
Hotfix
A small, urgent change shipped to repair a problem in production, usually outside the normal release schedule and reviewed afterwards.
Incident correlation
Matching an alert or incident to the deployments that could have caused it, and resolving the match to the commit, pull request and ticket behind it. Read more →
Lead time for changes
How long a change takes to reach production, measured from a fixed start point such as the first commit to running in production. One of the four DORA keys. Read more →
Preflight
The set of checks run on a release before it ships. In ArcRelease, seven checks are each judged pass, warn, fail or not checked, and the release receives a GO, NO-GO or CONDITIONAL verdict with the reasons attached. Read more →
Release candidate
A build that is believed ready to release and is under final testing and approval. If it passes, it is the version that ships.
Release dependency
A relationship in which one release cannot safely ship, or work, until another has shipped. May be hard (blocking) or soft (advisory). Read more →
Release intelligence and governance layer
A layer above the tools that run releases, which joins their signals into a dependency graph, an audit trail and a verdict. It reads the tools; it does not build or deploy. Read more →
Release management
The practice of planning, coordinating and controlling how software changes move to production: what ships, in what order, with whose approval and in which window, with a record of the decision. Read more →
Release manager
The person accountable for getting releases into production safely, coordinating scope, order, approvals and timing, and making or facilitating the go/no-go call. Read more →
Release train
A fixed, recurring release schedule that several teams ship on together, so a change either makes the next train or waits for the one after.
Rollback
Returning a system to its previous version after a deployment fails. Planning how to roll back, and whether data changes allow it, is part of release readiness.
Segregation of duties
The control principle that the person who writes a change is not the only person who approves or deploys it, so a second person has reviewed it. Read more →
Signed override
A recorded decision to ship past a failing check. In ArcRelease it requires an admin or release manager to sign a statement and attach at least one evidence link, and the preflight is snapshotted at that moment. Read more →
Soft dependency
A dependency that is advisory: it is better for the upstream release to ship first, but the downstream release is not broken without it. Read more →
Time to restore service
How long a service stays degraded after a failure, from the start of the incident to service restored. One of the four DORA keys, also called MTTR, and in recent DORA reports failed deployment recovery time. Read more →

Stop guessing at go/no-go.

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.

See the platform

Free plan · ten minute setup · we reply in one to two business days