What is the difference between DevOps and continuous delivery?
The tech world is full of buzzwords; DevOps is undoubtly one of the best-known of the last few years. Essentially DevOps is a concept that attempts to solve two key problems for modern IT departments and development teams – the complexity of a given infrastructure or service topology and market agility.
Or, to put it simply, there are lots of moving parts in modern software infrastructures, which make changing and fixing things hard. Project managers who know their agile inside out – not to mention customers too – need developers to:
- Quickly release new features based on client feedback
- Keep the service available, even during large deployments
- Have no lasting crashes, regressions, or interruptions
How do you do that ? You cultivate a DevOps philosophy and build a continous integration pipeline. The key thing to notice there are the italicised verbs – DevOps is cultural, continuous delivery is a process you construct as a team. But there’s also more to it than that.
Why do people confuse DevOps and continuous delivery?
So, we’ve established that there’s a lot of confusion around DevOps and continuous delivery (CD). Let’s take a look at what the experts say.
DevOps is defined on AWS as:
“The combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.”
Continuous Delivery, as stated by Carl Caum from Puppet,
“…is a series of practices designed to ensure that code can be rapidly and safely be deployed to production by delivering every change to a production-like environment and ensuring that business applications and services function as expected through rigorous automated testing.”
So yes, both are about delivering code. Both try to enforce practices and tools to improve velocity and reliability of software in production. Both want the IT release pipeline to be as cost effective and agile as possible. But if we’re getting into the details, DevOps is focused on managing challenging time to market expectations, while continuous delivery was a process to manage greater service complexity – making sure the code you ship is solid, basically.
Human problems and coding problems
In its definition of DevOps, Atlassian puts forward a neat formulation:
“DevOps doesn’t solve tooling problems. It solves human problems.”
DevOps, according to this understanding promotes the idea that development and operational teams should work seamlessly together. It argues that they should design tools and processes to ensure rapid and efficient development-to-production cycles.
Continuous Delivery, on the other hand, narrows this scope to a single mentra: your code should always be able to be safely released. It means that any change goes through an automated pipeline of tests (units, integrations, end-to-end) before being promoted to production. Martin Fowler nicely sums up the immediate benefits of this sophisticated deployment routine: “reduced deployment risk, believable progress, and user feedback.”
You can’t have continuous delivery without DevOps
Applying CD is difficult and requires advanced operational knowledge and enough resources to set up a pipeline that works for the team. Without a DevOps culture, you’re team won’t communicate properly, and technical resources won’t be properly designed. It will certainly hurt the most critical IT pipeline: longer release cycles, more unexpected behaviors in production, and a slow feedback loop. Developers and management might fear the deployment step and become less agile.
You can have DevOps without continuous delivery… but it’s a waste of time
The reverse this situation, DevOps without CD, is slightly less dangerous. But it is, unfortunately, pretty inefficient. While DevOps is a culture, or a philosophy, it is by no means supposed to remain theoretical. It’s supposed to be put into practice. After all, the main aim isn’t chin stroking intellectualism, it’s to help teams build better tools and develop processes to deliver code. The time (ie. money) spent to bootstrap such a culture shouldn’t be zeroed by a lack of concrete actions. CD delivery is a powerful asset for projects trying to conquer a market in a lean fashion. It overcomes the investments with teams of developers focused on business problems anddelevering to clients tested solutions as fast as they are ready.
Take DevOps and continuous delivery seriously
What we have, then, are two different, but related, concepts in how modern development teams understand operations. Ignoring one of them induces waste of resources and poor engineering efficiency. However, it is important to remember that the scope of DevOps – involving an entire organizational culture, potentially – and the complexity of continuous delivery mean that adoption shouldn’t be rushed or taken lightly. You need to make an effort to do it properly. It might need a mid or long term roadmap, and will undoubtedly require buy-in from a range of stakeholders.
So, keep communication channels open, consider using built cloud services if required, understand the value of automated tests and feedback-loops, and, most importantly, hire awesome people to take responsibility.
A final word of caution. As sophisticated as they are, DevOps and continuous delivery aren’t magical methodologies. A service as critical as AWS S3 claims 99.999999999% durability, thanks to rigorous engineering methods and yet, on February 28, it suffered a large service disruption. Code delivery is hard so keep your processes sharp!
About the author
Xavier Bruhiere is a Senior Data Engineer at Kpler. He is a curious, sharp, entrepreneur, and engineer who has built many projects, broke most of them, and launched and scaled what was left, learning from them all.