DevOps is a way of working in which the people who write software (development) and the people who run it (operations) share responsibility for getting changes into live use safely and often, with the building, testing and releasing done by automation. For a business, it means a requested change can reach users in days, a release stops being a risky event that needs a weekend, and a fault is found and put right quickly.
DevOps is not a product or a job title, although both exist under the name. Microsoft sells a set of tools called Azure DevOps, and many companies employ DevOps engineers. The word describes the practice those tools and people support.
The problem DevOps solves
In the traditional arrangement, developers wrote the software and handed it to a separate operations team to install and keep running. The two had opposite goals. Developers were judged on delivering change, and operations on keeping things stable, which change threatens. Releases were therefore made large and infrequent, each one carried months of changes, and when something broke it was hard to tell which change was responsible.
In a small business the same problem shows up differently. There is no operations team. Releasing means one developer copying files to a server by hand, following steps that exist only in that person’s memory. The release works when that developer is available and careful, and is a risk when they are not.
| Manual release | Automated release | |
|---|---|---|
| Who can do it | The person who knows the steps | Anyone authorised, by pressing a button |
| Testing before release | Whatever there was time for | The same automated tests every time |
| Size of each release | Large, because releases are painful | Small, because releases are routine |
| If it goes wrong | Work out what changed, fix it live | Return to the previous version, then investigate |
| Record of what was released | Depends on someone writing it down | Kept automatically |
The practices, in plain English
Version control. Every change to the code is stored with who made it, when and why, and any earlier version can be recovered. In DevOps this extends to configuration and database changes, so that the whole system can be recreated from what is stored.
Continuous integration. Developers merge their work into the shared code frequently, at least daily. Each merge triggers an automatic build and a run of the automated tests, so a change that breaks something is caught within minutes.
Automated testing. Tests written as code check that the system still does what it did before. Without them, releasing often is reckless. Our article on regression testing explains the idea.
Continuous delivery. DORA, the research programme that has studied this field since 2014, defines continuous delivery as “the ability to release changes of all kinds on demand quickly, safely, and sustainably”. The software is always in a state that could be released, and releasing is a business decision, not a technical project. Continuous deployment goes one step further and releases every change automatically once it passes its tests. Most business systems need the first and not the second.
Infrastructure as code. The servers, databases and network settings the system runs on are described in files and created by a tool, not set up by hand. A test environment can then be made to match the live one, and the live one can be rebuilt after a failure.
Monitoring. The running system reports its own health: errors, slow pages, failed jobs. The team should learn about a fault from an alert, before a customer rings.
Shared responsibility. The team that builds the system also cares how it runs. When something fails, the review asks what in the process allowed it, not who to blame.
The automated sequence that takes a change from a developer’s machine through build, test and release is called a pipeline. Azure Pipelines, GitHub Actions and GitLab are common tools for running one.
How to tell whether it is working
DORA publishes a small set of measures of software delivery. They cover how long a change takes to reach production, how often changes are deployed, how quickly a failed deployment is recovered, what share of deployments cause a problem, and what share are unplanned fixes for an incident. The full list and definitions are in our article on measuring productivity with agile metrics.
The most useful finding from that research is that speed and stability are not a trade-off. In DORA’s words they “are not tradeoffs”, and the measures move together for most teams. Releasing small changes often is safer than releasing large changes rarely, because each release contains less that can go wrong and is easier to reverse.
This matters more now that much code is written with AI assistance. DORA’s 2025 report, titled State of AI-assisted Software Development, describes AI’s main role as “an amplifier, magnifying an organization’s existing strengths and weaknesses”. A team with automated tests and a dependable pipeline can absorb more code written faster. A team without them simply produces untested changes more quickly.
What DevOps is not
It is not the same as agile. Agile methods deal with deciding what to build and in what order. DevOps deals with getting what was built into use. They work well together, and our overview of software development methodologies covers the agile side.
It does not require releasing every day. The aim is to be able to release whenever the business wants, without drama. A system that is released monthly through an automated pipeline is in better shape than one released weekly by hand.
It is not only for the cloud or for large companies. The practices apply to a single application on a single server. A small team gains most, because it has the least time to spend on manual releases.
It does not remove the need for operations knowledge. Someone still has to understand hosting, security updates and backups. DevOps changes where that knowledge sits, not whether it is needed.
DevOps for an older business system
Much of what is written about DevOps assumes new software built for the cloud. Many businesses run something older: a .NET Framework application and a SQL Server database on a Windows server, maintained by one or two people and released by hand.
The same practices apply, taken in order:
- Put all the source code in version control, and confirm that what is stored matches what is running.
- Make the build repeatable, so that the system can be produced from its source code on a clean machine.
- Create a test environment that resembles the live one.
- Script the release, including database changes, so that it runs the same way every time.
- Add automated tests around the parts that would hurt most if they broke.
- Test that a backup can be restored.
This is also where a takeover has to start. When we take over an existing system, the first step is to prove that it can be built from its source code, released in a controlled way and restored from a backup. Until those three are true, every change carries more risk than it should, and ongoing software maintenance is harder to do well.
Questions to ask your developer or supplier
You do not need to be technical to find out where you stand. Ask:
- Is every change to our system recorded in version control, and can we see it?
- When a change is approved, which steps take it to live use, and which of them are done by hand?
- How many people are able to release a change?
- Is there a test version of the system that we can log in to?
- If a release went wrong this afternoon, how would we go back to the previous version?
- How would you know the system had a fault before we told you?
- When was a backup last restored as a test?
Clear answers suggest the practices are in place, whatever they are called. Vague answers to the first two are the place to start.