Software deployment process flowchart: build to production
A software deployment process flowchart: build and version the artefact, quality gate, registry promotion, staging checks, canary rollout, automatic rollback.
How it works
Rename the lanes to your real roles
Replace Developer, CI/CD pipeline, QA, Release engineer and Operations with the roles you actually have. Many teams have no release engineer, in which case merge that lane into whoever owns production rather than leaving an empty band. Keep the CI/CD pipeline as its own lane even though it is automation, because the point of the chart is to show which steps a machine performs and which a person still performs.
Say what the artefact is and where it lives
Write down the artefact type (container image, package, bundle), the versioning scheme, how the version is derived from the commit, which registry holds it and how long it is retained. Then state the rule the rest of the chart depends on: build once and promote the same artefact, never rebuild per environment. If your pipeline currently rebuilds, mark that on the diagram, because it breaks the link between what was tested and what shipped.
Define what each gate actually checks
"Quality gate passed?" is only as useful as its definition. State which test suites must be green, what flake or coverage tolerance you accept, which security and dependency scans block the build, and who may override a red result. Do the same for the staging smoke and integration checks, and list the known differences between staging and production (data volume, third-party sandboxes, scaled-down infrastructure) so everyone knows what a healthy staging run does and does not prove.
Fix the change window and who opens it
Record when deployments may run, who approves them, and what happens to a deployment that is not approved. Note whether this deployment type is pre-authorised under a standing change model or needs an individual approval each time, and name the person who can approve one outside normal hours. If a held deployment simply waits for the next window, say how long the artefact stays valid before it must be rebuilt and retested.
Pick a strategy per service and write the rollout steps
Choose blue-green or canary for each service and put the choice on the chart. Then write the mechanics: the traffic increments, how long you observe between them, which health checks run at each step, and what the canary is compared against. Handle database changes separately, because a schema migration is usually the reason a rollback is not just a switch back; separating expand and contract migrations from the code deployment keeps the old version runnable.
Make the rollback trigger measurable, then publish the chart
Replace "someone notices" with a signal the pipeline can evaluate: error rate or latency against the service level objective, over a stated observation window, with an agreed action. Rehearse the rollback so you know how long it takes. Then share the diagram next to the runbook, capture sign-off from the people named in it, keep one current version, and review it after any deployment that went badly.
Frequently asked questions
What is the difference between a deployment process and a release process?
The release process decides what ships and whether it should: which changes are in scope, when scope freezes, who signs off UAT, and whether the go/no-go call is yes. The deployment process is the mechanics underneath that: build an artefact once, version it, promote it, verify it in staging, move it onto production infrastructure and roll it back if it misbehaves. The relationship is not one to one. A single release can involve several deployments, and plenty of deployments happen with no release attached, for example when code ships behind a feature flag and is enabled later. This template covers the mechanics; if you need scope freeze, UAT sign-off and a go/no-go gate, use the software release process template instead.
What are the stages of a software deployment process?
Five stages cover most teams. Build and version: merge the change, build the artefact once from a clean checkout and stamp it with its commit. Test and quality gate: run the automated tests and scans, and send failures back to the developer rather than forward. Staging: promote the artefact to the registry, deploy it to staging and run smoke and integration checks against it. Approval and window: request the production change window and get the deployment approved, or hold it for the next one. Production rollout: deploy blue-green or canary, shift traffic in steps with health checks, roll back automatically if the error budget is breached, otherwise complete the rollout, monitor it and close the deployment record.
Should we deploy blue-green or canary?
Blue-green runs two production environments and switches traffic between them, so the previous version stays warm and switching back is close to instant. The cost is roughly double capacity during the deployment, and every user moves at the moment of the cutover, so a problem that only appears under real traffic hits everyone at once. Canary sends a small share of real traffic to the new version first, which surfaces problems synthetic checks miss, but it needs traffic routing and metrics that can be sliced by version, it takes longer, and it knowingly exposes some users to a version you are not yet confident in. Neither one solves database changes: both assume the previous version can still run against the current schema, which is why migrations are usually split into expand and contract steps that are deployed separately.
When should a deployment roll back automatically?
When a signal the pipeline can evaluate on its own crosses an agreed threshold, not when someone interprets a dashboard. In practice that means error rate, latency or a named business transaction measured against the service level objective over a defined observation window, with the rollout paused or reversed automatically if the error budget burn is worse than the agreed limit. Two things make this work. First, rehearse the rollback so you know it functions and how long it takes. Second, keep the deployment reversible by separating irreversible steps, chiefly schema migrations and one-way data changes, from the code deployment, otherwise the automation will attempt a rollback the data cannot support.
Where does approval fit if we deploy several times a day?
Approving each deployment individually does not scale, and a process people cannot follow gets bypassed. The usual answer is to authorise the route rather than the instance: define this deployment type as a pre-approved standard change, with the pipeline's gates, tests and automatic rollback as the control, and reserve individual approval for changes that fall outside that model, such as schema migrations or anything touching a restricted environment. That is where the "Deployment approved?" decision sits in this chart, and it is why the held branch is drawn. Frameworks such as SOC 2 (criterion CC8.1) and ISO/IEC 27001's change management control expect changes to production to be authorised, tested and documented; they do not require a human signature on every deployment. A diagram is not evidence in itself, but the deployment records, test results and approvals it produces are what an assessor asks to see.