Use case 05 · Release
Preparing a release
Scope mismatch, unmerged PRs, failed gates and an outdated runbook can all cause a late surprise.
The work already crosses these systems:
Before and after
From scattered checks to one governed run.
Today
The release manager filters Jira by fix version, checks GitHub for merged PRs, checks CI/CD gates, updates the Confluence runbook and submits a ServiceNow change for CAB approval.
With NopsAI
A main pipeline with reusable checks verifies scope against merged PRs, validates CI/CD gates, pauses before production, and generates release notes and the change request together.
Same checks, same approval path, same evidence, every release.
Governed run
The run, step by step.
Deterministic work first, reasoning inside a boundary, and a named human before anything high-risk executes.
Trigger
A tag push or a scheduled release window starts the run.
Collect context
Fix-version scope, merged pull requests, gate status and the release runbook are assembled.
Verify state
Reusable check steps compare declared scope against what actually merged and flag every gap.
Reason
A release-reviewer agent role summarizes risk and proposes a go or no-go decision with reasons.
Approve
The production approval team signs off; the run holds state without occupying a runner.
Execute and record
Release notes and the change request are generated as run-owned outputs and linked to the run.
Evidence
What the run leaves behind.
The useful part is not only the automation. It is repeatability with proof.
Trigger and subject
What started the run and which effective identity it ran as.
Authorization snapshot
Which resources were checked, and which decision each check returned.
Tool and AI activity
Every tool call, the profile that allowed it, and the model usage it consumed.
Approvals and outputs
Who approved, when, and the deliverables the run produced.
← QA is blocked on unclear requirements
QA loses time reconstructing intent. Testing can start from the wrong assumption and clarification cycles cost a day or more.
A CI/CD pipeline suddenly starts failing →
Most failures are a diagnosis problem before they are an engineering problem, and diagnosis eats the first thirty minutes.
Map this workflow against your controls.
Bring the trigger, the tools it touches, the approvers, the runtime boundary and the evidence you need to keep.