The idea
DevOps joins building software (development, or Dev) with running it (operations, or Ops). One team owns the whole loop. It sends small changes round it often and lets machines do the repetitive work.
Dev: plan to test
A shop's basket shows 0.30000000000000004 instead of 0.3, because computers store 0.1 and 0.2 only approximately. The team plans one small change: round the total to cents. Small changes are quick to check and easy to undo.
A developer edits one line: total now returns round(sum(prices), 2). They commit it to version control (a shared history of every change, such as Git). That commit sets the rest of the loop moving.
Continuous integration (CI): a CI server notices the commit, fetches the code and builds it into a package that can run. No one does this by hand, so it happens the same way every time.
Then CI runs the automated tests. This one checks that total([0.1, 0.2]) is 0.3. Without round the answer is 0.30000000000000004, the test fails and the change goes back to the developer.
Ops: release to monitor
The tested package is saved as a numbered release that could go live at any moment. Keeping every change in that ready-to-ship state is called continuous delivery (CD). Here the Dev half hands over to Ops.
Automation installs the release on the servers. The servers are described in code files too (infrastructure as code), so a tool can build identical ones every time. Deploying every passing change automatically is continuous deployment.
The change is live: shoppers now see 0.3. The people who wrote it also help run it, so nothing is thrown over a wall to another team. This shared ownership is the heart of DevOps.
Monitoring watches the live service. Google's SRE book names four golden signals: latency, traffic, errors and saturation. What the team learns feeds the next plan, and the loop goes round again.
Measuring the loop
DORA, a long-running research programme at Google, measures delivery with four keys. Two are about speed: deployment frequency, how often you deploy to production, and lead time for changes, from commit to running in production.
Two keys are about stability: change failure rate, the share of deploys that break something, and time to restore, how long until it works again, say by rolling back. DORA finds speed and stability are not a trade-off: top teams do well on both.
What happens
;; step 1/11 · devops
Dev plan → code → build → test
Ops release → deploy → operate → monitor
…then back to plan
one team owns both halves
small changes, often
machines do the repeatable work
The eight-stage infinity loop is a common teaching picture, not a standard. Real teams name and split the stages differently, and many stages overlap or run at the same time. DORA (DevOps Research and Assessment) now calls these change lead time, deployment frequency, change fail rate and failed deployment recovery time, and its current guide adds a fifth metric, deployment rework rate. The figure uses the four classic names.