CI/CD Pipeline Flowchart: From Commit to Production
A CI/CD pipeline turns every change into a tested, deployable build. Continuous integration (CI) builds the code and runs automated tests on each commit. Continuous delivery or deployment (CD) then ships the same build to staging and to production.
This flowchart does not depend on a tool. It fits GitHub Actions, GitLab CI, Jenkins, AWS CodePipeline or any other runner. What matters is the order of the gates: nothing reaches production unless it passed the tests and a check in an environment that looks like production.
Scroll sideways to see the whole diagram
Start from this diagram and edit it on your own board.
By continuing, you agree to the Terms of Service and Privacy Policy, including sending images of your strokes, diagram labels and similar data to providers in the United States (Cloudflare, Inc. and TypeSafe AI, Inc.) for AI conversion.
What each part does
- Commit pushed
- The trigger. A push or a merged pull request on the main branch starts the pipeline.
- Build and package
- Compiles the code and produces one artifact, such as a container image or a zip file. Build once: every later stage deploys this same artifact.
- Run tests
- Unit and integration tests, plus lint and type checks. They are fast and decide whether the change may continue.
- Tests pass?
- The first gate. A failure stops the pipeline here.
- Deploy to staging
- Releases the artifact to an environment that mirrors production, with its own configuration and data.
- Smoke tests pass?
- The second gate: a few quick end-to-end checks that the deployed app starts, responds and can reach its dependencies.
- Deploy to production
- Releases the same artifact that passed in staging, ideally with a gradual rollout and a single step to go back.
- Released
- The end of a successful run. Monitoring takes over from here.
- Notify the author
- The failure path from either gate. The pipeline stops and tells the person who made the change, through chat, email or the pull request, with a link to the log.
How a change flows
- A commit lands on the main branch and triggers the pipeline.
- The build stage produces a single versioned artifact.
- Tests run against the build. If any fail, the pipeline stops and notifies the author.
- The artifact is deployed to staging, and smoke tests run against it.
- If the smoke tests fail, the pipeline stops and notifies the author.
- If they pass, the same artifact is deployed to production and the run ends.
When to use it
- Documenting how a team releases software, for onboarding or for a review of the process.
- Agreeing on the gates before choosing a tool: what has to pass before production?
- A starting point for a real pipeline. In most CI systems one box becomes one job or stage.
Common variations
Add a manual approval
Put an approval step between staging and production when a person must sign off, for example in regulated systems.
Roll out gradually
Replace the production step with a canary or blue/green deployment, and roll back automatically when the error rate rises.
Add security and quality checks
Add dependency scanning, secret scanning and static analysis next to the tests, so they fail the same gate.
Run checks in parallel
Run lint, unit tests and integration tests as parallel jobs to shorten the wait. The gate then waits for all of them.
Make it yours
Rename the stages after the jobs in your tool, then add the gates your team really has, such as a security scan or a manual approval.
Opens this diagram as a board you can edit.
By continuing, you agree to the Terms of Service and Privacy Policy, including sending images of your strokes, diagram labels and similar data to providers in the United States (Cloudflare, Inc. and TypeSafe AI, Inc.) for AI conversion.