DevOps
Also called: dev ops, platform engineering
Making the path from a developer's commit to running software fast, automated and reversible — and treating that path as a product with an owner.
Originally a cultural argument about developers and operations sharing responsibility. In practice today it means someone owns the pipeline, the environments and the infrastructure definitions, and that ownership is a full job rather than a side effect of being the least able to say no.
What it looks like when it is working
Deploys are boring. They happen during the working day because nobody needs to watch them. Rolling back is a revert, and it has been tested recently. Every environment can be recreated from code, so staging and production do not quietly diverge.
What it looks like when it is not
Releases on Thursday evenings. Staging that drifted eighteen months ago. Someone changing infrastructure in a cloud console at 2am and nobody knowing afterwards. A rollback plan that has never been executed.
None of that is unusual, and none of it requires a transformation programme to fix. It requires an owner.
What a DevOps engineer actually does
Less "culture change agent," more the person who owns CI, the infrastructure definitions, the deploy tooling and the alerts that page someone at 2am. The role exists because someone has to be accountable for the whole path, not because a team read a book about collaboration.
The pieces that make it up
- CI — every commit is built and tested automatically, so broken code is caught in minutes, not in staging.
- CD — a build that passes can reach production without a ticket, a meeting or someone's calendar.
- Infrastructure as code — environments defined in version control instead of a person's memory of what they clicked in a console.
- Observability — metrics, logs and traces that answer "what broke" before a customer has to ask.
Skip one of these and the others end up compensating for it badly.
DevOps versus SRE versus NoOps
DevOps is the delivery path. SRE is the discipline of keeping the running system reliable, with error budgets and on-call. NoOps is a commercial arrangement where someone else does both and carries the pager.
They overlap heavily and the labels matter less than whether anyone is accountable.
The common mistake
Buying tools instead of assigning ownership. A CI platform, a Kubernetes cluster and an observability vendor do not add up to DevOps if no one is responsible for the result. See our DevOps service for what we actually do.
FAQ
Questions about this term
What is DevOps in simple terms?
The practice of making software releases routine and automated instead of risky one-off events, and giving someone the job of owning that path end to end.
What does a DevOps engineer actually do?
Owns CI/CD pipelines, infrastructure definitions and the monitoring that says something has gone wrong — not, primarily, mediating between developers and ops.
Is DevOps a job title or a methodology?
Both, unhelpfully. It started as a set of practices; most companies now hire for it as a role, faster than the industry agreed on what to call the work.
What is the difference between DevOps and Agile?
Agile is about how a team decides what to build next. DevOps is about how what they built gets to production and stays running. You can do either without the other, though teams that do one well tend to end up doing both.
What tools do I need to do DevOps?
Nothing specific — a CI system, an infrastructure-as-code tool and somewhere to see logs and metrics cover most of it. See our DevOps service for what a typical stack looks like.