Software release process flowchart
A software release process flowchart covering scope freeze, the automated test gate, staging and UAT, go/no-go approval, deployment, rollback and hotfixes.
How it works
Rename the lanes to your real roles
Replace Development, QA, Release manager, Operations and Product owner with the roles you actually have. Plenty of teams have no dedicated release manager, in which case merge that lane into engineering leadership rather than leaving an empty band. If you have no separate operations team, fold deployment into Development and say so on the chart.
Define what the scope freeze means
Write your freeze rule next to the branch-cut step: what may still land on the release branch after the cut, who authorises an exception, and how the branch is tagged. Record the commit the branch came from, because that is what makes the build reproducible and lets you generate release notes from the diff.
Define what "pass" means at each test gate
The "Automated tests pass?" decision is only as good as its definition. State which suites must be green, what flake or coverage threshold you accept, and who may override a red build. Do the same for the staging regression pack and for UAT, so the product owner knows what they are signing off.
Write the go/no-go criteria before you need them
Replace the generic decision with your own checklist: no open critical defects, rollback rehearsed, on-call cover confirmed, dependent teams notified, and a stated cut-off time. Name who chairs the call and who can veto. Agreeing this while a release is already waiting is how bad releases get approved.
Set the rollback trigger, the soak period and the hotfix route
Say what makes "Release healthy?" answer failing: a specific error rate, latency threshold or failed smoke test, not a judgement call. Set how long the soak period runs and what is watched. Then decide what approval a hotfix needs, who can authorise one out of hours, and how it is merged back to the mainline, since a fix that lives only on the release branch is a common source of the next regression.
Publish it and keep one current version
Share the diagram where the work happens, next to the release checklist or in the runbook, and capture sign-off from the people named in it. Keep the earlier versions so you can show when the procedure changed and why, and review it after any release that went badly.
Frequently asked questions
What are the stages of a software release process?
Five stages cover most teams. First, scope and branch: agree what is in the release, confirm test entry criteria, freeze scope and cut the release branch. Second, build and test: produce a release candidate, run the automated suite, and send failures back to the branch instead of forward. Third, staging and UAT: deploy to a staging environment, run regression tests, and get UAT sign-off from the product owner. Fourth, approval: assemble a readiness record and make an explicit go/no-go decision. Fifth, release and monitoring: deploy in the agreed window, run smoke tests, watch for a defined soak period, then publish release notes and close the release.
What is the difference between a release process and a deployment pipeline?
A deployment pipeline is the automation: it builds, tests and ships code on a trigger. The release process is the decision-making around it, including who agreed the scope, who confirmed the tests were meaningful, who approved production, what happens when the release goes wrong and when the team can stand down. A mature pipeline removes manual steps but it does not remove the decisions. This chart deliberately shows the decisions as decisions, so you can see which of them your pipeline already enforces and which still rely on someone remembering.
Who should make the go/no-go decision, and what should it be based on?
One named person should chair it, usually the release manager or whoever owns production, with the product owner's approval already recorded as an input rather than debated on the call. Base it on criteria written before the release: no open critical defects, regression and UAT complete, rollback rehearsed, on-call cover confirmed, dependent teams notified. Record who attended and what was decided, not just the outcome. If you are audited under SOC 2, the relevant criterion is CC8.1, which expects changes to be authorised, tested, approved and documented; the readiness record and the approval trail are what evidence that, and the diagram shows where they are produced.
How should hotfixes be handled without bypassing the release process?
A hotfix compresses the process, it does not skip it. In this template a defect found during the monitoring period routes to "Build and test a hotfix" in the Development lane, then re-enters at deployment and goes through the same production smoke tests and the same "Release healthy?" check as a planned release. What changes is the approval speed, not the verification. Two rules keep it honest: agree in advance who can authorise a hotfix out of hours, and merge the fix back to the mainline the same day, because a fix that exists only on the release branch reappears as a regression in the next release.