The problem DevOps tries to solve
Traditionally, one group of people wrote software and another group ran it. Developers were often rewarded for shipping new features quickly. Operations staff were rewarded for keeping systems stable. Those goals pull in opposite directions, because every change is a possible source of instability.
The result was a familiar pattern. Developers finished work and handed it over. Operations received something they had not seen before, with unclear instructions, and had to find out how it behaved in the real environment. When something broke, each side could reasonably say the problem started on the other side of the wall.
DevOps is the name for a set of habits that try to take that wall down. The word is a blend of “development” and “operations.” It is not a job title, a product or a certification you can buy; it is a way of organizing work so that the people who build a system and the people who run it share goals, information and responsibility.
The core ideas
Different writers describe DevOps differently, but most descriptions return to the same handful of ideas.
Shared ownership. The team that builds a service takes part in running it. People who are woken up by a failure tend to care about making that failure less likely, and people who run a system can raise problems while a design is still cheap to change.
Small, frequent changes. A release containing three weeks of work is hard to test and hard to reason about when it fails. A release containing one small change is easier to review, easier to roll back and easier to diagnose. Teams that adopt DevOps habits usually try to shrink the size of each change rather than waiting for a big launch.
Automation of repeatable work. Anything done the same way many times, such as building software, running checks or setting up a server, is a candidate for being done by a script or a tool instead of by hand. Manual steps are slow and vary from person to person. The idea is covered more fully in the discussion of task automation, which looks at how to pick jobs worth automating.
Fast feedback. The sooner a mistake is noticed, the cheaper it is to fix. Automated tests, review of changes and good visibility into running systems all shorten the time between making an error and learning about it.
Learning from failure. Things will go wrong. Teams that do well tend to treat an outage as information about the system rather than as a reason to find someone to blame. A blameless post-incident review is a common way to do this: describe what happened, what people knew at the time and what could change.
The practices that support those ideas
The ideas above show up in day-to-day practices. None of them is required for a team to say it works in a DevOps way, and teams adopt them in different orders.
- Version control for everything that matters. Application code is the obvious case, but configuration files, scripts and documentation can be tracked in the same way, which gives a history of who changed what and why.
- Automated build and test pipelines. Each change is built and checked automatically, which is the heart of continuous integration.
- Automated, repeatable releases. Getting a tested change into production follows a defined path instead of a hand-written checklist.
- Describing environments in files. Servers and networks are set up from written definitions, so that two environments can be made to match and a lost one can be rebuilt.
- Monitoring and alerting. The team can see how a system is behaving and is told when something needs attention.
- Lightweight change management. Rather than long approval queues for every tweak, risk is managed by making changes small, tested and reversible, though some organizations still need formal approvals and DevOps habits can sit alongside them.
What DevOps is not
A few misunderstandings are common.
It is not simply a set of tools. Buying a pipeline product does not create shared ownership, and a team can have an impressive toolchain while developers and operators still barely speak. Tools help, but the habits come first.
It is not the end of specialists. A team can still have people who are especially strong in networks, databases or security. The change is that they work with the builders from the start instead of receiving finished work.
It is not only for large technology companies. Some of the ideas, such as keeping scripts in version control or writing down how a server was set up, are useful for an IT team of two people.
It is also not a guarantee of speed or reliability. Adopting these practices tends to help, but results depend on the organization, the system and how consistently the habits are applied.
Security and compliance
Some people worry that frequent changes and less formal handoffs weaken security. They can, if checks are skipped. Done carefully, the opposite is possible: automated checks such as vulnerability scanning can run on every change, and the principle of least privilege can be applied to the accounts that pipelines use. The practices of keeping a record of every change and of testing before release also give auditors something concrete to examine. Regulated organizations usually adapt the ideas to their rules rather than ignoring either.
Starting small
A team does not need a transformation program. A sensible first step is to pick one painful, repeated manual task and make it reliable. Another is to put existing scripts and configuration files into a shared repository so that changes can be reviewed. A third is to hold a short, blameless review after the next incident and write down one concrete improvement.
Good early questions to ask are: where do we wait on each other, which steps are done by hand and differently each time, and how do we find out when something has broken? The answers usually point at the next useful change.
Progress tends to be gradual. Teams often find that the cultural parts, such as talking earlier and sharing responsibility, matter as much as any technical step, and that the technical steps stick better when people understand the reason for them.