DevOps
Also known as: development and operations, DevOps culture
DevOps is a set of cultural values and practices that bring software development and IT operations together, so teams share responsibility for building, releasing, and running software.
It relies heavily on automation, such as CI/CD and infrastructure as code, and on fast feedback from production. While 'DevOps engineer' became a job title, the movement's founders meant it as a way of working, not a team you can hire.
DevOps, explained at three levels
At home
Imagine the people who design a car never talking to the mechanics who fix it. Problems keep repeating. DevOps puts software builders and the people who run the software on the same team, so problems get fixed at the source.
At work
DevOps helps companies release improvements faster with fewer outages. Developers and operations staff share goals, tools, and responsibility, instead of handing work over a wall.
At home
DevOps practices include automating builds and tests, deploying small changes often, monitoring software in production, and learning from failures without blame. 'You build it, you run it' is a common slogan.
At work
Common DevOps tools include CI/CD pipelines, infrastructure as code, containers, and observability platforms. Frameworks such as CALMS (culture, automation, lean, measurement, sharing) summarize the principles, and DORA metrics measure progress.
At home
Many companies renamed their operations team 'DevOps' without changing how anyone worked together. In my opinion, that's how DevOps became a buzzword: tools are easy to buy, but shared responsibility is hard to create.
At work
DevOps has spawned related disciplines: SRE (an engineering approach to reliability), platform engineering (internal self-service tools), and DevSecOps (security built into the pipeline). Choose based on bottlenecks: if developers are overwhelmed by infrastructure, platform engineering helps; if reliability lacks discipline, SRE does.
Real-world examples
At home
Thomas works the help desk at a small software firm. After the company adopted DevOps practices, developers joined the on-call rotation. Bugs that used to linger for months got fixed quickly once developers felt the late-night pages themselves.
At work
Carlos is the IT director at a Canadian credit union where developers and operations blamed each other for every failed release. Combining them into product teams with shared metrics and automated deployments cut failed releases by more than half within a year.
Common confusions
- DevOps is a job title or a team. — It's a way of working across teams. Titles and teams can help but don't create the culture.
- DevOps means developers do all operations work. — It means shared responsibility, often supported by platform teams and automation.
- Buying DevOps tools makes you a DevOps organization. — Tools support DevOps, but culture, feedback, and shared goals are the core.
For analysts
If releases trigger blame between teams, that's a DevOps problem, not a tooling one. I'd start by giving developers and operations one shared measure of success, like DORA metrics, before buying anything.
History & origin
In 2008 and 2009, Patrick Debois and Andrew Shafer discussed 'agile infrastructure,' and John Allspaw and Paul Hammond's 2009 talk at Velocity, '10+ Deploys Per Day,' showed developers and operations working as one. Debois organized the first DevOpsDays in Ghent, Belgium, in October 2009, giving the movement its name. The 2013 novel The Phoenix Project, by Gene Kim, Kevin Behr, and George Spafford, spread the ideas to executives, and DORA's research gave them evidence. Cloud computing and containers then made automation cheap. In my view, DevOps' original insight still holds: the wall between people who write software and people who run it was causing most of the pain.