What Is A DevOps Pipeline? Stages, Tools & How To Build One

A team ships a hotfix on a Friday afternoon. It clears CI in four minutes, deploys itself to production with zero human sign-off, and nobody finds out until Monday that a config value pointed at the wrong environment.

That’s a DevOps pipeline doing exactly what it was built to do: move code fast. Elite engineering teams deploy multiple times a day. Etsy famously ran more than 50 production deploys in a single day back in 2014, using a fully automated pipeline with heavy application monitoring built in, according to InfoQ.

Speed isn’t the failure in the Friday scenario above. The failure is treating every pipeline like it should optimize for the same thing.

A pipeline built for a consumer app and a pipeline built for a system that touches safety, money, or regulatory compliance shouldn’t look the same.

What is a DevOps pipeline?

A DevOps pipeline is the set of automated processes and tools that move code from a developer’s commit through build, test, and deployment into a production environment. Monitoring data then feeds back into the next cycle.

The defining trait is continuity, not any single tool

Each stage runs automatically and repeatedly, triggered by a code change, not scheduled as a one-off event the way a manual release used to be.

A pipeline also spans two teams’ work by design. Developers write, build, and test the code, while operations deploy, run, and monitor it. The whole point of calling it a “DevOps” pipeline rather than just a “build” pipeline is continuity. Those two jobs are stitched into one continuous system, instead of being handed off between departments that don’t talk to each other.

A simple example of how it runs

A developer commits a change to a shared repository. That commit triggers an automated build, which compiles the code and resolves dependencies. If the build succeeds, an automated test suite runs against it. If the tests pass, the change moves toward a release and eventually into production, without anyone manually copying files or running a deployment script by hand.

Why does the stage count keep changing

How many stages does a DevOps pipeline have? Here’s our answer: the question itself is the wrong one. The real disagreement isn’t about counting stages. It’s about scope, and once that’s separated, the argument mostly evaporates.

The CI/CD-only view: 5 to 6 stages

When we count just the automation loop, the part a CI/CD tool actually runs, we land on five or six stages. That version starts at code commit and ends at deploy, sometimes folding release into deploy as a single step.

The full-lifecycle view: 7 to 8 stages

When we count the full software development lifecycle, including the human work on either end, we land on seven or eight stages. That version adds planning before the code gets written and live operations after the deploy finishes, because a pipeline that stops updating the second code hits production isn’t really continuous.

Which count should you use?

Neither count is “the” answer. One is answering “what’s automated here,” and the other is answering “what’s the whole delivery lifecycle look like?”

Pick the framing that matches what you’re actually trying to build. If you’re wiring up your first automated build-test-deploy loop, think in five or six stages. If you’re designing how planning, delivery, and operations connect across a whole engineering process, think in seven or eight stages.

The core stages of a DevOps pipeline

Here’s the full-lifecycle version, since it gives the most complete picture of what each stage is actually responsible for.

1. Plan. The team defines the change, breaks it into tasks, and agrees on what “done” looks like before anyone opens an editor.
2. Code. Developers write and commit changes to a shared, version-controlled repository, usually on a short-lived branch that merges back frequently.
3. Build. The commit triggers an automated build. Dependencies resolve, the code compiles, and the result is a deployable artifact.
4. Test. Automated unit, integration, and regression tests run against the build. A failure here stops the pipeline before the change goes any further.
5. Release. The tested build gets packaged and marked ready. Some teams gate this step with manual approval. Others let it flow straight through.
6. Deploy. The release moves into a target environment, usually staging first and production second, often through a blue-green or canary strategy that limits how much traffic hits the new version before it’s proven stable.
7. Monitor. Post-deployment observability tracks performance and errors in production, and that data feeds straight back into planning for the next cycle.

Stage 5, Release, is the one most often merged into Deploy in the shorter framings. That single step, folding Release into Deploy, is the whole reason the five-stage and seven-stage counts diverge.

DevOps pipeline vs. CI/CD pipeline: What’s actually different

A DevOps pipeline and a CI/CD pipeline aren’t interchangeable, even though most explanations treat them that way. The difference comes down to scope, not tooling.

In practice, ask someone to set up “the CI/CD pipeline” and they’ll build the automation. Say “the DevOps pipeline” instead, and they usually mean the whole system around it, including the people.

The tools that power each pipeline stage

DevOps pipeline tools fall into five functional categories:

• Orchestration and CI/CD engines
• Testing and security
• Infrastructure as code
• Containerization
• Monitoring and observability

Grouping them this way answers “what do I actually need” better than an alphabetical list ever could.

Orchestration and CI/CD engines

These run the automated build-test-deploy sequence. Jenkins carries the largest installed base of any CI/CD tool and is heavily plugin-driven, though GitHub Actions has overtaken it for new-project adoption. GitHub Actions and GitLab CI/CD sit natively inside the repository platform most teams already use.

Azure Pipelines, CircleCI, Harness, Argo Workflows, and Tekton cover everything from cloud-hosted convenience to Kubernetes-native pipeline execution, depending on where the workloads actually run.

Testing and security tools

These catch problems before they reach production. Static analysis and dependency scanning tools, such as Snyk and SonarQube, typically run at commit or build time. They flag vulnerable dependencies and code-quality issues before a human reviewer looks at the diff.

Infrastructure as code tools

Terraform and Ansible belong in this conversation, not off to the side. The environment a pipeline deploys into needs to be as version-controlled and repeatable as the code itself.

Containerization tools

Docker and Kubernetes, chief among them, add steps the plain seven-stage list doesn’t show explicitly. That includes building an image, pushing it to a registry, and orchestrating it across a cluster.

Monitoring and observability tools

These close the loop back to the Monitor stage, tracking application and infrastructure health in production and surfacing the data that feeds the next planning cycle.

Pick tools by which stage is currently your actual bottleneck, not by which vendor publishes the loudest blog.

Where DevOps pipelines actually break

Most pipeline failures start small, as slow-building trust problems that eventually cause a real outage.

Flaky tests that erode trust in automation

A test that fails intermittently, with no code changes involved, teaches a team to re-run the build instead of trusting it. That’s exactly the maintenance burden AI test automation is designed to remove. That quietly defeats the entire purpose of automated testing.

Research on Google’s internal continuous integration data, cited in a University of Illinois study, found that roughly 1.5% of all test runs in Google’s CI pipeline were flaky. Nearly 16% of individual tests failed for reasons unrelated to actual code or test changes.

Poor failure visibility

Generic logs with no stage-by-stage reporting turn a five-minute fix into an hours-long investigation. Nobody can tell whether a failure happened during build, test, or deploy without rerunning the whole thing.

Skipped rollback planning

Tests passing doesn’t guarantee production behaves the same way. A team that hasn’t rehearsed rolling back finds that out at the worst possible time. GitOps is one way teams close that gap. An operator continuously reconciles the live system against a declared state and reverts drift on its own.

Security treated as a final gate

Vulnerabilities and hardcoded credentials slip through a DevOps pipeline when scanning happens once at the end instead of continuously, as a pipeline-wide practice. Shift left security, the DevSecOps practice of scanning at every stage rather than just before release, is what closes that gap in a DevSecOps pipeline.

Teams without the bandwidth to wire this up in-house often bring in a partner. Eastgate’s product engineering practice builds CI/CD pipelines with SonarQube and Snyk scanning built into every quality gate, not bolted on before release.

Why this adds up to a deployment frequency gap

According to Snyk, Harness’ 2020 Continuous Delivery Insights report found the average company deployed code to production only once every four days.

High-performing teams close that deployment frequency gap by running their DevOps pipeline more often, in smaller batches. Pipeline automation is what makes that cadence possible. Smaller, more frequent changes are also easier to test. They’re easier to roll back, too, and less prone to failure in the first place.

Building a pipeline for regulated or mission-critical systems

A pipeline for a regulated or mission-critical system, one tied to safety, financial transactions, or regulatory compliance, needs deliberate friction that the generic model doesn’t build in.

Manual approval gates matter more than automated test coverage

Take a mission-critical system that runs continuously, such as a centralized traffic-signal-performance platform. It’s integrated with a live regional signal network and held to a strict uptime requirement. Even when every automated test passes, a human still holds the release gate before anything reaches production. That’s a deliberate trade of a few minutes of deploy speed for accountability on a system that can’t tolerate a bad release.

Eastgate built exactly this kind of system for a US transportation agency, a signal performance measures platform that held 99% uptime while cutting travel time by 15 to 25%.

Compliance context also means audit trails that record who approved a release and when. Rollback plans get tested and timed before go-live, instead of being improvised after an incident. Staging environments mirror production’s data handling and access controls, in addition to its configuration.

The standard for industrial and OT contexts

For manufacturing, industrial, and energy-grid contexts, IEC 62443-4-1 is the standard to point to. It covers secure product development lifecycle practices for industrial automation and control systems, making it a concrete framework to design a pipeline around.

How to build a DevOps pipeline: A practical starting point

1. Pick one CI/CD tool and commit to it before evaluating a second option. Tool paralysis costs more time than picking an imperfect tool at this stage.
2. Put source control at the center of everything. Every later stage reads from and reports back to the repository.
3. Automate the build and a minimal test suite first. Even three fast tests running on every commit beat zero automated tests.
4. Add a staging environment that mirrors production as closely as budget allows before automating deployment itself.
5. Automate deployment last, not first. Manual deploys with everything else automated are a safer intermediate state than the reverse.
6. Instrument monitoring before you need it. Set up alerting before the first production incident happens, not while it’s happening.

Final thoughts

A DevOps pipeline is simple in concept. It’s automated stages moving code from commit to production, but the right version of it depends entirely on what’s being built. The stage-count debate, the tool sprawl, and the failure points covered above all trace back to the same unresolved question: is this pipeline optimizing for speed, or for governance?

Before adopting any pipeline template wholesale, ask which stage in the current process actually causes the most pain. That’s the stage worth automating first, regardless of which one every guide happens to start with.