DevOps

DevOps is a way of organising software delivery so that the people who build a system and the people who run it share responsibility for it. It is not a job title or a single tool. It combines cultural change with technical practices such as automation, version control for everything and fast feedback.

How it works

The idea took shape in the late 2000s, as teams struggled with a handoff model in which developers wrote code and operations teams deployed and supported it. Shared ownership shortens feedback loops: the team that ships a change also sees how it behaves in production.

In practice this means small, frequent changes moving through an automated pipeline (see CI/CD), infrastructure defined in code (see infrastructure as code), and monitoring that tells the team whether a release is healthy.

The CALMS framework

CALMS is a common checklist for assessing maturity: Culture (shared ownership), Automation (pipelines and infrastructure as code), Lean (reduce waste and work in progress), Measurement (use data to decide) and Sharing (blameless post-mortems, runbooks, documented knowledge).

A practical example

A team wants to release more often without more incidents. It starts by measuring delivery. The DORA research programme describes throughput measures (change lead time, deployment frequency, failed deployment recovery time) and instability measures (change fail rate, deployment rework rate). The team records a baseline, automates the slowest manual step in its pipeline, and re-measures. Reliability targets are agreed using SLIs, SLOs and SLAs, so speed is balanced against stability.

Common mistakes

• Renaming the operations team “DevOps” without changing responsibilities or incentives.
• Buying tools first and hoping behaviour follows.
• Automating a broken process instead of simplifying it.
• Measuring individuals rather than the delivery system, which encourages gaming.
• Skipping blameless reviews, so the same incidents recur.

When to use it and when not to

The practices apply to nearly any team that ships software, but the right depth varies. A small team may need only a reliable pipeline and basic monitoring. A larger organisation may need platform engineering and formal on-call. DevOps is a poor fit as a slogan for a one-off project that will never change, or where regulation demands separation of duties that must still be met through controls such as approvals and audit trails. Managed support is an option when in-house capacity is limited: see managed DevOps.

See also

• CI/CD
• Infrastructure as Code
• SLI, SLO, SLA
• GitOps
• Managed DevOps