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.
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.