The eight stages of the DevOps loop — and where teams break

Most teams that say they "need DevOps" already have the tools. There is a CI server, a container registry, probably a Kubernetes cluster someone set up. What is missing is not tooling. It is an agreed standard for each stage of the loop that everyone actually follows.

Without it you get the familiar pattern: one service deploys from a pipeline, another from a laptop. Tests are skipped when a release is urgent. Nobody is certain what runs on which server, and the person who set it up has left. Releases become risky events, so they get postponed, so each one gets bigger and riskier still.

Here is the loop, stage by stage, with the failure you will recognise in each.

1. Plan

The failure: nobody agrees what "done" means, and there is no baseline, so nobody can tell whether anything is improving.

The standard: a defined way work enters the system, an agreed branching and environment strategy, and a measured starting point. Measure your delivery performance before changing anything — otherwise every later claim of improvement is a feeling.

2. Code

The failure: three branching models in one organisation, reviews that comment on formatting while missing design problems, and credentials committed to the repository "temporarily".

The standard: one branching model everyone uses. Formatting enforced automatically so review time goes to logic. Secrets never in version control — enforced by tooling, because good intentions fail under deadline.

3. Build

The failure: "works on my machine". Builds that depend on what happens to be installed on a particular laptop, dependencies unpinned so yesterday's build cannot be reproduced.

The standard: every commit builds automatically and reproducibly. Pinned dependencies, versioned artifacts in a registry, and identical behaviour locally and on the server.

4. Test

The failure: a suite so slow and flaky that people re-run it until it passes. Once a team learns to ignore a red build, the tests have negative value — they cost time and provide no signal.

The standard: fast unit tests, meaningful integration tests against real dependencies, and a thin end-to-end layer. Quality gates that block, and that are trusted enough nobody asks to bypass them. A flaky test is a bug to fix, not a nuisance to tolerate.

5. Release

The failure: releasing is an event. It happens at night, needs several people awake, and is preceded by a long checklist someone follows from memory.

The standard: semantic versioning, one artifact built once and promoted through environments rather than rebuilt per stage, clear approvals and automatic changelogs. Releasing becomes a decision rather than an operation.

6. Deploy

The failure: deployment is manual, or automated but not repeatable. Environments differ from production in ways nobody documented. Rollback exists in theory and has never been tested.

The standard: automated deployment to environments that genuinely match production, health checks that gate traffic, and a rollback that has been rehearsed. Blue-green or canary where the complexity earns its place — not everywhere by default.

7. Operate

The failure: knowledge lives in one person's head. There is no runbook, on-call is whoever answers, incidents are handled heroically and the same one recurs a month later. Backups exist; restoring from them has never been tried.

The standard: runbooks for what actually breaks, a humane rotation, a blameless incident process that produces changes rather than blame, and backups that have been restored in a drill. Plus cost visibility, before the invoice becomes the alert.

8. Monitor

The failure: either nothing is monitored, or so much is that alerts are ignored. Both end the same way — you learn about outages from customers.

The standard: logs, metrics and traces in one place. SLIs and SLOs defined around what users actually experience. Alerts tuned so a page means action. An alert nobody acts on is worse than no alert, because it trains people to ignore the channel.

Closing the loop

Monitor feeds back into Plan. That is what makes it a loop rather than a pipeline. What you learn in production — which changes caused incidents, where lead time is lost, which service pages people at night — should shape what gets planned next.

Teams that skip this connection keep improving the parts they can see and never address the thing actually hurting them.

How to know whether it is working

Four measures tell you nearly everything:

• Deployment frequency — how often you release.
• Lead time for change — commit to production.
• Change failure rate — how often a release causes a problem.
• Time to restore — how quickly you recover when it does.

The first two measure speed, the last two stability, and the useful finding is that they rise together. Teams that release more often break things less, because small changes are easier to verify and easier to reverse. If your organisation treats speed and safety as a trade-off, that assumption is the thing to fix first.

Where to start

Not everywhere. Take the honest baseline, then fix the stage where your friction actually is. For most teams that is build and deploy automation, because everything downstream depends on it. For others it is testing, or the fact that nobody can restore a backup.

Pick one stage, set the standard, make it stick, then move on. A standard that covers the whole loop and is followed by nobody is worth less than one stage done properly.