A DevOps pipeline is the automated sequence of steps that takes a code change from a developer's commit to running in production — typically build, test, security scan, artifact packaging, deploy, and monitoring — with as little manual intervention as possible. If you can describe how a commit becomes a release at your company, you have described your pipeline, whether or not you ever drew it.
The word "pipeline" earns its name: each stage feeds the next, and a failure at any stage stops the flow before a bad change reaches users.
What are the stages of a DevOps pipeline?
Most pipelines, whatever the tooling, pass through the same seven stages:
- Source. A developer pushes to a shared repository — a
git branchmerged through a pull request is the usual entry point. Branch protection rules decide what is allowed in. - Build. The CI server compiles code or bundles the application, resolving every dependency declared in the manifest.
- Test. Unit and integration tests run automatically. A red test stops the pipeline — that is the whole point.
- Security scan. Static analysis (SAST) reviews your code, software composition analysis (SCA) checks your dependencies, and secret detection catches committed credentials before they ship.
- Package. The build becomes an immutable artifact — a container image, a signed binary, a versioned package — stored in a registry.
- Deploy. The artifact is promoted through environments: staging, canary, production. Progressive delivery (blue-green, rolling, canary) limits blast radius.
- Operate and monitor. Metrics, logs, and alerts close the loop; what you learn in production feeds the next commit.
Smaller teams collapse stages; regulated teams add approval steps. The sequence stays recognizable.
Which DevOps pipeline tools does each stage use?
The devops pipeline tools landscape is crowded, but the categories are stable:
| Stage | Common tools |
|---|---|
| Source | GitHub, GitLab, Bitbucket |
| Build/CI | GitHub Actions, GitLab CI, Jenkins, CircleCI, Buildkite |
| Test | Jest, Pytest, JUnit, Playwright |
| Security | SAST, SCA, DAST, and secret scanners — ideally one platform, not four consoles |
| Package | Docker, Artifactory, Nexus, cloud registries |
| Deploy | Argo CD, Flux, Spinnaker, Terraform |
| Monitor | Prometheus, Grafana, Datadog, OpenTelemetry |
Tool choice matters less than integration: a pipeline is only as fast as its slowest stage and only as trustworthy as its least reliable one.
Where do security gates belong in a DevOps pipeline?
The devops best practices answer is: as early as the signal allows, and always before an irreversible step.
- Pre-commit / PR: secret scanning and linters — cheap checks with instant feedback.
- Build: SCA on the resolved dependency tree, because that is the first moment you know exactly what you are shipping. Manifest-only scans miss transitive dependencies.
- Post-build: SAST on the full codebase, container image scanning on the packaged artifact.
- Pre-deploy: policy gates — block on critical, reachable vulnerabilities rather than raw CVSS scores, or the gate becomes noise the team learns to override.
- Post-deploy: DAST against the running application, where runtime-only issues surface.
A gate that fails builds for unreachable, low-severity findings gets disabled within a quarter. A gate that blocks only what is genuinely exploitable earns the team's trust. Platforms like Safeguard consolidate SCA, SAST, and DAST results into one policy so the pipeline has a single, explainable pass/fail decision.
How do you build a DevOps pipeline without slowing delivery?
Speed and safety are not opposites; slow pipelines are usually badly ordered pipelines.
- Run independent stages in parallel — tests and SAST do not need to wait for each other.
- Cache dependencies and build layers; most build time is repeated downloads.
- Fail fast: put the quickest checks first so broken commits die in seconds, not after a 20-minute build.
- Keep the pipeline definition in the repository (
pipeline as code) so changes are reviewed like any other code. - Measure it. Lead time from commit to production is the honest metric of pipeline health — it is one of the DevSecOps metrics that predict real outcomes.
FAQ
What is a DevOps pipeline in simple terms?
It is the automated assembly line for software: every commit is built, tested, scanned, packaged, and deployed by machines following the same checked-in recipe, so releases are repeatable instead of heroic.
What is the difference between CI and CD in a pipeline?
Continuous integration (CI) covers build and test on every change. Continuous delivery/deployment (CD) covers packaging and promoting the artifact to environments — delivery stops at "ready to deploy," deployment goes all the way to production automatically.
Are DevOps pipeline stages the same as SDLC phases?
They overlap but are not identical. The SDLC describes the full lifecycle including planning and design; the pipeline automates the stretch from committed code to operated software.
What is a security gate in a DevOps pipeline?
A pipeline step that evaluates findings from scanners against policy and stops the pipeline when the policy fails — for example, "no critical, exploitable vulnerabilities in a deployable artifact." Good gates are strict about reachability and quiet about noise.