A Brief History of DevOps, Part IV: Continuous Delivery vs. Continuous Deployment

Continuous Delivery vs. Continuous Deployment

What is the difference between continuous delivery vs. continuous deployment? The biggest difference is that continuous delivery requires a manual step to deploy and continuous deployment does not.

(To hear our latest insights on the history and future of DevOps listen to our podcast from The Confident Commit.)

What is continuous delivery?

Continuous delivery is the practice of ensuring that software is always ready to be deployed. Part of that insurance is testing every change you’ve made. In addition, you’ve also made the effort to package up the actual artifacts that are going to be deployed — perhaps you’ve already deployed those artifacts to a staging environment.

Continuous delivery requires continuous integration. It relies on the same underlying principles: cutting work into small increments.

Think back to that time when we explained what continuous integration was. We talked a lot about the advantages of constantly merging bits of code — all in the name of avoiding enormous code conflicts at the end of a development cycle. People were excited to reap the rewards of this methodology.

The difficulty found in this quick adoption was that developers washed their hands of code they pushed to production, safe in the knowledge that it was “someone else’s problem”. Operators began to dread changes from the other side.

The collaboration was at an all-time high on the development side: developers were coming together to merge their code before releasing it; however, the operational end of continuous delivery hadn’t been modernized in the same way. There was still distance between what the developers made and “the real world”, and customers can’t use a product if it hasn’t been released.

Developers + Operators = DevOps

DevOps is the synergy of development and operation. It’s the idea that code isn’t serving its purpose until it’s been delivered. This is something that both developers and operators can agree on. Another thing they can agree on is that the reason code isn’t delivered is often because of fear. What if we make a big change and it breaks something critical?

Big changes mean big risks and these can mess with operational stability.

Without continuous delivery, developers and operators are equally stressed by the same thing — the act of deploying a lot of code. And the purpose of continuous delivery is to make the act of deploying much less scary.

What is continuous deployment?

Continuous deployment is the methodology of creating a robust testing framework and automatically pushing your code out when tests pass.

Remember, big changes require small changes. So if developers actually committed to committing small changes, there shouldn’t be much harm in automatically deploying changes that pass all tests.

Proper continuous deployment is difficult because it is hard to know if you have exhaustive test coverage. Teams usually need some amount of breathing room between development and deploys, especially for sensitive changes like database migrations.

Continuous deployment also encourages other kinds of continuous action, like analytics, error reporting, and testing. Rollbar ties code changes to error frequency and key organizational metrics. PagerDuty shares the operations load across the team and makes error resolution less hectic.

Moving forward with DevOps

There are two ways to respond to this world of constant flux: you can double down on creating the “perfect” unchanging plan. Or you can build incrementally, gaining valuable feedback as you go, and know you’ll never get too far off course. As developers and operators continue to collaborate on shipping better code more frequently these groups will learn lessons from one another: developers will think about performant code, and operators will grease the wheels of deployment.

It’s impossible to predict the future, so focus on understanding the present. This is the belief behind the DevOps movement, the monitoring of services, the constant shipping. It’s become the way to effect meaningful change.

Build your software delivery team

What does a high-performing software delivery team look like? At CircleCI, we analyzed over millions of data points from tens of thousands of organizations building on CircleCI to find out how teams can set meaningful goals, and share data-backed benchmarks for engineering teams. Download our data report, The 2023 State of Software Delivery to learn more.

(This blog is part four of a four-part series. Read parts Part I: Waterfall, Part II: Agile Development, and Part III: Automated Testing.)