The DevOps lifecycle
The lifecycle diagram everyone draws as an infinity symbol — Plan, Code, Build, Test, Release, Deploy, Operate, Monitor — is usually taught as eight boxes to memorize. This page teaches it as a loop instead: by the end, you should be able to say exactly what closes the circle from Monitor back to Plan, and why a team that treats it as a straight line from Plan to Deploy is missing the point of DevOps entirely.
Think of a thermostat, not an assembly line. An assembly line runs Start to Finish once and stops. A thermostat measures the room (Monitor), compares it to the target temperature (Plan), and adjusts (Code/Build/Deploy) — forever, in a loop, because the room keeps changing. The DevOps lifecycle is a thermostat for software: it never "finishes," it keeps sensing and correcting.
Eight stages, one circuit
The lifecycle is usually drawn as an infinity loop rather than a straight pipeline specifically to signal that Deploy is not the finish line. Each stage has a distinct job, a representative practice, and a representative category of tooling:
- Plan. Purpose: decide what to build next and why, informed by both business priority and production reality. Practice: backlog refinement against a prioritized issue tracker, sized in small increments. Tool category: issue/work tracking software.
- Code. Purpose: turn a plan item into a change a machine can build and test. Practice: trunk-based development or short-lived feature branches with small, frequent commits — see version control & branching for the branching-strategy trade-offs. Tool category: a distributed version control system.
- Build. Purpose: turn source into a reproducible, versioned artifact. Practice: a fully automated, deterministic build triggered on every commit — same inputs, same output, every time. Tool category: a build automation / CI runner.
- Test. Purpose: catch defects and regressions before a human ever sees them in production. Practice: a layered test suite (unit, integration, contract) that runs automatically on every build and gates promotion. Tool category: an automated test framework and runner.
- Release. Purpose: decide that a specific, already-tested artifact is fit to ship and package it for delivery. Practice: semantic versioning plus an immutable, signed release manifest — the artifact that gets deployed is bit-for-bit the one that was tested. Tool category: an artifact repository / release manager, covered further in build & artifact management.
- Deploy. Purpose: move the released artifact into a live environment with minimal risk and minimal downtime. Practice: progressive delivery — canary or rolling deployment with an automated rollback trigger. Tool category: a deployment/orchestration platform, detailed in deployment strategies.
- Operate. Purpose: keep the deployed system running, scaled, and configured correctly under real load. Practice: infrastructure defined as code and reconciled continuously against a declared desired state. Tool category: infrastructure-as-code and configuration-management tooling.
- Monitor. Purpose: observe what the system is actually doing — performance, errors, and usage — and turn that into signal, not just noise. Practice: instrumenting the four golden signals (latency, traffic, errors, saturation) with alerting thresholds tied to user-facing impact, not raw CPU. Tool category: a metrics/logging/tracing observability stack.
The feedback arrow is the whole point
Seven of the eight arrows in the diagram just describe a delivery pipeline: Plan feeds Code, Code feeds Build, and so on down to Monitor. That much is true of any structured software process, DevOps or not. The eighth arrow — Monitor back to Plan — is the one that makes it a lifecycle instead of a lifecycle-shaped pipeline, and it's the one teams skip when they adopt the tooling without the practice.
Concretely, that arrow means production telemetry is a direct input to backlog prioritization, not a separate concern owned by a different team. An error-budget burn observed in Monitor (see monitoring & observability) becomes a Plan item — pay down reliability debt — with the same priority mechanics as a feature request. A recurring alert that pages the same service three times in a sprint becomes a Plan item to fix the root cause, not just staff more on-call. A slow p99 latency trend becomes a Plan item to profile and optimize before it becomes an incident, which is exactly the discipline covered in incident management.
Without that arrow, "Monitor" degenerates into a dashboard nobody acts on, and "Plan" degenerates into a backlog driven entirely by feature requests with zero signal from what's actually breaking in production. The loop only works as a loop if the output of the last stage is a required input to the first one — not an optional Slack notification someone might glance at.
Where the boundaries actually sit
The eight-stage split is useful pedagogically but the real boundaries in a working system are softer than the diagram suggests, and knowing where they blur matters more than memorizing the list:
- Build and Test are usually one automated job, not two — a single CI pipeline stage that compiles, links, and runs the fast test tiers before it ever produces an artifact worth naming. See CI/CD pipelines for how that pipeline is actually structured stage by stage.
- Release and Deploy are distinct decisions even when they happen seconds apart: Release answers "is this artifact fit to ship," Deploy answers "is it live right now." Feature flags exist precisely to separate them further — you can deploy code that isn't released to users yet.
- Operate and Monitor overlap heavily with Test in a mature setup — synthetic monitoring and canary analysis are, functionally, tests that run continuously in production instead of once in CI.
None of this contradicts the eight-stage model; it just means the stages describe purposes, not necessarily eight separate tools, teams, or approval gates. A two-person team can run all eight stages through one CI/CD platform and still be doing every stage's job.
Why "faster deploys" alone doesn't fix a broken loop
A common failure mode is optimizing deploy frequency — the metric everyone can see — while leaving the feedback arrow disconnected. A team can ship to production ten times a day and still be flying blind if nothing routes production signal back into planning. High deploy frequency with a broken feedback loop just means you ship the wrong thing faster.
Deploy frequency and lead time (both DORA metrics, covered in measuring success) measure the delivery half of the loop only. They say nothing about whether Monitor output is actually reaching Plan. A team can look excellent on those two numbers while still re-litigating the same production incident every quarter because nobody closed the loop back to backlog priority.
The practical test for whether your organization's loop is real: pick a specific alert or dashboard from last week and trace it forward. If you can point to a specific backlog item it produced — not "we discussed it," an actual ticket with a priority and an owner — the loop is closed. If the trail goes cold at the dashboard, you have a pipeline, not a lifecycle.
What the loop looks like day to day
In practice, most teams run several trips around this loop concurrently at different speeds. A hotfix might go Plan-to-Deploy in under an hour for a single stage; a platform migration might spend weeks in Plan and Code before its first Build. What stays constant is the shape, not the duration: every change, regardless of size, passes through the same eight purposes in the same order, and every deployed change eventually produces monitoring data that becomes an input somewhere in the loop's next lap. The DevOps toolchain page maps each stage above onto the specific categories of tools teams wire together to automate it end to end.
The lifecycle isn't eight sequential steps that happen once — it's a loop that keeps running, and the arrow from Monitor back to Plan is not optional decoration on the diagram. If your organization's version of this loop has no mechanism for production data to change what gets planned next, you don't have a DevOps lifecycle yet, no matter how automated the Build-to-Deploy half is.
1. Name the eight stages of the DevOps lifecycle in order. 2. Which single arrow in the diagram is what actually makes it a "loop" rather than a "pipeline," and what does it carry? 3. Give one concrete example of production monitoring data becoming a Plan-stage backlog item. 4. Why can a team with excellent deploy frequency still have a broken lifecycle?
Check your answers
- Plan, Code, Build, Test, Release, Deploy, Operate, Monitor.
- The feedback arrow from Monitor back to Plan — it carries production telemetry (errors, latency, usage, incident patterns) that becomes an input to what gets prioritized next, not just a dashboard someone might look at.
- For example: an error-budget burn or a repeated on-call page for the same root cause turns into a prioritized backlog ticket to fix the underlying issue, rather than staying a Monitor-stage alert nobody acts on.
- Deploy frequency only measures the delivery half of the loop (Plan through Deploy). A team can ship fast and still have no mechanism routing Monitor's output back into Plan, so it keeps shipping without ever correcting course based on what production is actually telling it.