CI/CD Pipeline — from commit to production
A CI/CD pipeline on an interactive canvas: commit, build, tests, packaging, deployment to staging and production, and the gates that decide whether a release stays.
CI/CD automates the path from a code commit to production: continuous integration builds and tests every change, and continuous delivery packages and deploys it through gates that decide whether the release is healthy enough to stay.
CI/CD Pipeline — from commit to production
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Read the five columns left to right: Commit, Build and test, Package, Deploy, Monitor.
- Follow the change across the lanes: it leaves the developer, is processed by the CI server, sits in the registry, and runs on the deployment target.
- The two decisions are gates — a "No" at either one sends the change to an explicit failure endpoint instead of forward.
Building and testing
"Developer commits code" starts the flow, and "CI server builds the application" and "Unit and integration tests run" are continuous integration's job: every commit is compiled and tested on its own. "All checks passed?" is the gate that gives CI its name — a failing commit is rejected at "Build failed — fix and recommit" before it can contaminate the artifact stream.
Packaging and deploying
"Package the artifact and push to the registry" produces the immutable, versioned build — the exact thing that will run. "Deploy to staging, run smoke tests" proves it in an environment like production, then "Deploy to production" ships it. The registry lane is the handoff: the artifact is built once and consumed by every later stage, which is what makes the deployed version identical to the tested one.
The monitoring gate
"Healthy after deploy?" is the final decision: metrics, logs and alerting after the release decide whether "Release is live and monitored" or "Roll back to the last good version". The rollback is drawn as a real step returning to the healthy end state, because automated rollback is what makes rapid deployment safe.
Key relationships and takeaways
- CI is the gate before anything ships: build and test every commit, and reject failures at the source.
- The artifact in the registry is built once and run everywhere — deployment reproducibility depends on it.
- Staging proves the artifact in a production-like environment before production sees it.
- Health after deploy is the real gate — monitoring, not the deploy script, decides whether a release stays.
- A pipeline without a rollback is not safe to automate; the canvas draws rollback as a first-class path.
When to use this visual
- Teaching a team the difference between continuous integration and continuous delivery before they build a pipeline.
- Designing a pipeline: the two gates say where automation must stop and judgement (or rollback) must start.
- Auditing an existing pipeline — a missing health gate is a release running without a decision.
How it works
Map your actual pipeline stages
Replace the generic stages with the ones your CI runs — lint, container build, migration, canary — keeping a gate before anything ships.
Name your checks
Annotate the test box with the actual suites and security scans you run, and what the "All checks passed?" gate requires beyond unit tests.
Add the canary branch
Insert a canary step between staging and production — route a small percentage of traffic to the new version and watch the health gate before full rollout.
Specify the rollback
On the rollback box, note what it actually does in your system — redeploy the previous image, restore a database backup — and who or what triggers it.
Frequently asked questions
What is the difference between CI and CD?
Continuous integration (CI) is the practice of building and testing every commit automatically, so problems surface the moment they are introduced rather than at release time. Continuous delivery (CD) takes the CI output and automates its path to deployment — packaging, staging, releasing — with gates deciding when it is safe. CI is the first gate in the pipeline, CD is everything after it.
Why are gates important in a CI/CD pipeline?
Because automation removes the human checkpoints that used to catch problems. The pipeline's gates replace them with decisions: the test gate stops a failing build before it ships, and the health gate stops a bad release after it ships. The visual draws both as decision shapes for this reason — a pipeline is only as trustworthy as its gates.
What is a rollback and why does the pipeline need one?
A rollback is returning the system to the last known-good version when a release fails after deployment. Pipelines need it because health checks are imperfect and production can misbehave in ways staging never showed. An automated rollback is what lets teams deploy frequently — the cost of a bad release becomes a revert, not an incident.
How does the artifact registry fit in?
The registry is where the pipeline's built artifact lives with a version. Every later stage — staging, production, rollback — deploys the exact artifact from the registry, never a rebuild. That is what makes the deployed code identical to the tested code, and it is also what makes rollback safe: the last good version is still in the registry.
Edit this visual in QueryChart (FlowJam)
Open this exact CI/CD canvas as your own chart, rename the stages to your pipeline, and add your real gates.