CI/CD Pipeline Flowchart
The code
flowchart TD
A[Push to main] --> B[Install dependencies]
B --> C[Run unit tests]
C --> D{Tests pass?}
D -- No --> E[Notify author]
D -- Yes --> F[Build artifact]
F --> G[Deploy to staging]
G --> H{Smoke tests pass?}
H -- No --> E
H -- Yes --> I{Approved for prod?}
I -- Yes --> J[Deploy to production]
I -- No --> K[Stop pipeline]
J --> L((Release live))
How this template works
This template documents a delivery pipeline as a flowchart: code is pushed, dependencies are installed, tests run, an artifact is built, staging is deployed and smoke-tested, and only after an explicit approval does anything reach production. It is the diagram to keep next to your CI configuration file, because the YAML that defines a pipeline and the picture your teammates hold in their heads are rarely the same thing. New hires use it to learn the path to production; reviewers use it to point at exactly which gate a change failed.
The syntax is a straight spine with gates. flowchart TD lays the pipeline out vertically, matching how most CI logs read. Rectangles are stages: B[Install dependencies], F[Build artifact], and so on. Diamonds are gates, and each gate has a labeled exit for each outcome — D -- No --> E[Notify author] and D -- Yes --> F[Build artifact]. Two details deserve attention. First, node E receives arrows from two different gates, the unit test failure and the smoke test failure; converging edges are completely legal and are how you show that different failures share one notification path. Second, the approval diamond I{Approved for prod?} has two labeled exits, Yes and No, and both must exist — an approval gate with only one drawn outcome hides the rejection path, which is precisely the path auditors ask about. The terminator L((Release live)) uses double parentheses to mark the successful end.
The gotcha is unlabeled gates. If you write D --> E and D --> F without the -- Yes --> and -- No --> labels, the diagram still renders but nobody can tell which arrow is which, and the picture becomes worse than no picture. Always label both exits of a decision diamond. A second trap is reusing a node id after deleting a stage: if you remove the build step but leave an edge pointing at its old id, Mermaid recreates an empty node in the middle of your pipeline.
To adapt it, mirror your real pipeline stages and delete the gates you do not have. If deploys are fully automated, replace the approval diamond with a direct edge, and consider adding a rollback rectangle after production for teams with an automated revert job.
Related templates: the fault handling flowchart for what happens when production misbehaves after this pipeline ships, the incident response flowchart for the on-call path a bad deploy triggers, and the release flow gitgraph for the branching model feeding the trigger node. The flowchart diagram guide covers every shape used here.
Variations to try
- Add a rollback rectangle after the production deploy for teams with an automated revert job.
- Insert a security scan step between build artifact and staging deploy to satisfy compliance review.
- Rename the trigger label to the branch your team actually ships from, such as a release branch.
