What a DevOps pipeline diagram shows
A CI/CD (Continuous Integration / Continuous Delivery) pipeline diagram maps the automated path from a code commit to a running system. It shows each stage in sequence — source control trigger, build, test, security scan, artifact publication, staging deployment, integration test, production deployment — along with the gates that block or allow progression between them and the tools operating at each stage.
A GitOps diagram follows the same general shape but changes who drives the deployment. In GitOps, a Git repository is the single source of truth for the desired cluster state. An operator such as Argo CD or Flux watches the repository and reconciles the live environment to match — the pipeline ends at a merge, and the operator handles the rest. Diagramming makes this pull-based distinction explicit.
An IaC (Infrastructure-as-Code) pipeline diagram covers the lifecycle of infrastructure changes: a Terraform plan, policy check (such as Sentinel or OPA), cost estimate, manual approval gate, and apply step, followed by drift detection. These pipelines typically run alongside application pipelines and are worth diagramming separately so reviewers can trace which infrastructure change accompanied which application release.
Engineers diagram pipelines for three primary reasons. First, onboarding: a new team member can trace the full path from commit to production in minutes rather than reading six YAML files. Second, incident review: a pipeline diagram anchors a post-mortem by showing exactly which stage should have caught the defect. Third, compliance: SOC 2, ISO 27001, and FedRAMP controls frequently require documented evidence of change management processes, and a pipeline diagram is the most efficient artifact to produce.
The difference between a pipeline diagram and a generic flowchart is specificity. A flowchart can model any decision sequence. A pipeline diagram has typed stages, defined artifact handoffs, explicit pass/fail gates, and parallel execution lanes. Generic flowchart tools produce shapes that resemble a pipeline but carry no semantic meaning about stage types or gate logic. flow-chart.io generates the pipeline-specific topology — each node is a typed stage object, each edge carries a pass or fail label, and parallel lanes are laid out as concurrent tracks.
Standard CI/CD pipeline stages
| Stage | Purpose | Common tools |
|---|---|---|
| Source | A push or merged pull request triggers the pipeline. Branch policies enforce required reviewers and status checks before merge. | GitHub, GitLab, Bitbucket, Azure DevOps |
| Build | Compile source code, resolve dependencies, and produce a container image or deployable artifact. A failed build blocks all downstream stages. | GitHub Actions, GitLab CI, Jenkins, CircleCI, Buildkite, Bazel |
| Test (unit) | Run fast, isolated unit tests against the build output. Target: under two minutes. High failure rate = fix tests or fix code, not skip the stage. | Jest, pytest, JUnit, Go test, RSpec |
| Security scan | Static analysis (SAST), dependency vulnerability audit, and container image scanning. Often runs in parallel with unit tests to keep the pipeline fast. | Snyk, Trivy, Semgrep, Checkov, GitHub Advanced Security, SonarQube |
| Artifact | Push the verified build artifact to a registry. Subsequent stages pull from the registry rather than rebuilding — the artifact is immutable from this point. | Docker Hub, AWS ECR, GCP Artifact Registry, GitHub Packages, JFrog Artifactory |
| Deploy staging | Deploy the artifact to a staging environment that mirrors production configuration. Staging should be the only environment where untested code runs on infrastructure identical to production. | Helm, Kustomize, Argo CD, Flux, AWS CodeDeploy, Spinnaker |
| Integration test | Run end-to-end and integration tests against the staging deployment. Tests exercise real service boundaries, databases, and external integrations. | Playwright, Cypress, k6, Postman/Newman, Testcontainers |
| Deploy production | Promote the artifact to production. Deployment strategy — rolling, blue/green, or canary — determines how traffic shifts. A manual approval gate is common here for regulated systems. | Argo Rollouts, Spinnaker, Flux, AWS CodeDeploy, Harness |
| Monitor | Observe the deployment in production: error rate, latency, saturation. Automated rollback triggers fire if SLOs breach thresholds within the bake window. | Datadog, Grafana, Prometheus, New Relic, PagerDuty, Honeycomb |
GitOps vs traditional CI/CD — how to diagram each
In a traditional push-based CI/CD pipeline, the pipeline itself executes the deployment: after tests pass, the pipeline calls the target environment's API (a kubectl apply, a Helm upgrade, a cloud provider deploy command) and waits for confirmation. The pipeline is the actor. A diagram of this model shows a linear sequence of stages ending in a deploy step with a direct arrow to the production environment.
In a GitOps model, the pipeline's job ends when it commits the new desired state to a configuration repository (often a separate "config repo" from the application source). A separate operator — Argo CD, Flux, or a similar tool — continuously watches that repository and reconciles the live cluster state against it. No pipeline step directly touches the cluster. A diagram of this model splits into two loops: the CI loop (source → build → test → push artifact → update config repo) and the CD loop (operator detects config change → diff → apply → health check → alert on drift). The two loops are distinct and should be drawn as separate but connected flows.
The visual distinction matters for incident review. If a production deployment diverges from the config repo, the cause is in the operator loop, not the CI loop. A diagram that conflates the two makes root-cause analysis harder. flow-chart.io generates each loop as a separate track and connects them at the config repo node, making the handoff explicit.
How to generate a DevOps pipeline diagram with flow-chart.io
- Create a free account — 40 AI credits/month, no credit card required.
- Select the DevOps / pipeline domain from the domain picker to tell the AI to generate pipeline-specific stage topology rather than a generic flowchart.
- Describe your pipeline in plain language — for example: "CI/CD pipeline using GitHub Actions and Argo CD. Source is GitHub. Build produces a Docker image pushed to ECR. Unit tests and Snyk scan run in parallel after build. Deploy to EKS staging, run Playwright E2E tests, then deploy to EKS production with a manual approval gate. Monitor with Datadog. Show a rollback path if production health checks fail."
- Edit and export — click any stage to rename, reposition, or update the tool label. Add parallel lanes, insert a missing gate, or split a stage. Export as SVG, PNG, or JSON when the diagram is ready.
Frequently asked questions
- What is a CI/CD pipeline diagram?
- A CI/CD pipeline diagram is a visual map of the automated stages that move source code from a developer's commit to a running system in production. It shows each stage (source, build, test, security scan, artifact registry, staging deploy, integration test, production deploy), the gates that control progression between them, the tools at each stage, and the paths taken when a stage fails. CI/CD pipeline diagrams are used for onboarding engineers, incident post-mortems, compliance audits, and architecture reviews.
- What is GitOps and how do I diagram it?
- GitOps is a deployment model in which the desired state of a system is declared entirely in a Git repository. An automated operator (such as Argo CD or Flux) continuously compares the live cluster state against the Git state and reconciles any drift. In a GitOps diagram, the pipeline terminates when a commit is merged into the environment branch — the deployment loop is driven by the operator, not a push step. flow-chart.io can generate both traditional push-based CI/CD diagrams and pull-based GitOps diagrams; describe your model and the AI applies the correct topology.
- What stages should appear in a DevOps pipeline diagram?
- At minimum: Source (code commit and PR trigger), Build (compile, containerize), Unit Test, Security Scan (SAST, dependency audit), Artifact (publish to registry), Deploy to Staging, Integration / E2E Test, Deploy to Production, and Monitor / Observe. Complex pipelines add parallel test shards, canary or blue/green deployment stages, manual approval gates, and rollback paths. All of these are first-class objects in flow-chart.io and can be added by describing them in plain language.
- How is a pipeline diagram different from a flowchart?
- A generic flowchart represents any decision-and-action sequence. A CI/CD pipeline diagram is domain-specific: it has a fixed left-to-right or top-to-bottom flow, typed stage nodes (build, test, deploy), explicit gate conditions (pass/fail), artifact handoffs between stages, and parallel execution lanes for simultaneous stages such as unit tests and security scans. flow-chart.io generates the pipeline-specific topology rather than generic diamond-and-rectangle flowcharts.
- Can I show parallel test stages in a pipeline diagram?
- Yes. Parallel stages — for example, unit tests, integration tests, and a security scan running simultaneously — are represented as a fork in the pipeline with a join gate that waits for all branches to pass before continuing. Describe the parallel stages in your prompt (e.g., "unit tests and SAST scan run in parallel after the build") and flow-chart.io places them on concurrent lanes with the correct fork and join connectors.
- What export formats does flow-chart.io support?
- You can export diagrams as SVG (vector, scales to any size), PNG (raster, for slides and documents), and JSON (the structured scene graph, suitable for re-importing into flow-chart.io or programmatic processing). SVG and PNG exports are available on all plans; JSON export is available on Pro and Team plans.
- Does flow-chart.io support IaC (Terraform, Pulumi) pipeline diagrams?
- Yes. Infrastructure-as-Code pipelines have distinct stages — plan, cost estimate, policy check, apply, drift detection — and often include approval gates before the apply step. Describe your IaC tool (Terraform, Pulumi, OpenTofu, Crossplane) and workflow, and flow-chart.io generates the correct stage sequence. You can include multiple environments (dev, staging, prod) as separate pipeline tracks in the same diagram.