Haut de page

Continuous Delivery vs. Continuous Deployment


Posted by
Sonia Lelii

April 26, 2018

DevOps has been described as a firm handshake between development and operations, meant to build better products at a faster pace. DevOps also has shined a light on a new set of practices, such as Continuous Delivery and Continuous Deployment. Although the two terms are often conflated, they have distinctions in how and when software changes are pushed out into production. It’s important to understand the differences between Continuous Delivery vs. Continuous Deployment because each have ramifications to the business.

The difference between these terms is like opening a Russian matryoshka doll, with the degree of automation and releases increasing as you move to the next level. Let’s take a look at what they have in common, such as their ties to Continuous Integration, and at what point the two CDs become different practices that often comes down to a balance between speed and quality.

What is Continuous Integration?

Both CDs benefit from a centralized location where changes are continuously merged and validated, preferably via automated testing. It’s a critical practice for a multiple-person development teams on a project. In the past, developers created code in isolation so Continuous Integration (CI) plays an important role in breaking down one of the barriers for a faster software development process.

CI encourages developers to share their code and unit tests by merging changes as often as possible into a shared version-control repository. This best practice evolved as a way to cut down on the amount of time it took to integrate code, which lead to merging conflicts and difficult bug fixes. CI also helps maintain a high level of quality code in the master branch repository.

CI can be applied even before the code is merged. When a developer wants to merge the code in the repository, the CI process will run all the automated tests and compilations on the code to check that it works, hence identifying issues early and leading to a greater quality of code.

CI builds efficiencies into feedback loop for code changes and bug fixes, raising the quality standard of the source code and avoiding potential issues down the line when they become harder to fix. Using CI with automated testing also speeds up the process. Plus, performing a series of automated tests validates the code at all levels of the product development.

CI typically works in two phases: It first makes sure the code compiles and then ensures the code works the way it was designed. A series of automated tests validates the code at all product levels, so developers do not have to sift through a haystack of code to find the bugs. CI requires you to configure a CI server that monitors the main repository. It also means developers must merge their changes continuously, while the team also has to write automated tests for each new feature.

The benefits means it will be easier to build the release since the integration problems were resolved earlier in the process and less bugs will exist in the production version. The cost includes the installation and maintenance of a CI server along with the maintenance of the test scripts.

What is Continuous Delivery?

Continuous Delivery goes even further with the automation process than CI. Not only is testing automated as it is in CI, but the release process is also automated. Continuous Delivery ensures that every change delivered to the staging environments, via complete automation, is ready for production deployment. However, there is usually a manual trigger to move code from tests to production.

Continuous Delivery’s strength lies in automatically deploying the code in the environments where it is needed, and then easily allowing that code to be promoted to ‘higher’ environments until eventually it reaches production.

Continuous Delivery is often used when you want the code-base to be in a ready-state of deployment and triggered to move into production at any given time, based on business requirements.  If your aim is to make less risky changes and ensure code is in a deployable state at any given time, even when the product is not 100 percent complete, then your preferred approach is Continuous Delivery. When we talk about a “deployable state,” we mean that available feature sets are vetted, tested, debugged and ready to deploy to production.

The idea is to keep the code base ready for when the decision is made to push code into production, whether it is done daily or weekly. In short, Continuous Delivery requires building, testing and releasing faster and more frequently. You release in smaller batches and more often, allowing for a quicker turnaround to identify bugs and fixes.

Here, it is important to have a strong CI foundation in order have a fluid Continuous Delivery process. CI automates both testing and builds, and these builds are then deployed as part of Continuous Delivery.  Automated builds, tests and deployments are part of one release workflow.

Continuous Delivery is targeted more for projects that develop products for end-user customers. The feedback loop between end-users and developers is seamless and accelerated. For Continuous Delivery to work, you need a strong CI foundation so your test suite can cover enough of your code-base. The work done in CI brings about better quality code, and Continuous Delivery expands upon CI to bring code to market faster.

What is Continuous Deployment?

Continuous Deployment involves code deployments that are automatic at every stage in the pipeline, so that customers see a stream of quality improvements daily compared to monthly or yearly. It takes Continuous Delivery one step further because each deployment is automatic every time a change is made. There is no pause in the development process and no human intervention – every change to the main branch that passes the CI test is pushed into production. Only a failed test will prevent a new change to be deployed to production.

Where to use Continuous Delivery vs. Continuous Deployment

While the DevOps culture has pushed the limits of the need for speed, one should take caution before jumping right into Continuous Deployment. While the current ecosystem dictates developers need to release fast to remain competitive, whether you release faster needs to be balanced with the number of users and the maturity of your team.

In the alpha version of your product, you can play around with Continuous Deployment. After all, you have zero users and nothing to lose. Once your ready to move to beta, you’ve defined the foundation of your Continuous Deployment process and testing culture.

Yet if you have an existing application and user base, you might need to start with a Continuous Integration approach and add Continuous Delivery as the next building block. Continuous Deployment dictates that the users are the actual testers. In order not to lose customers to buggy software, your team should be able to handle the workload of the documentation, support and marketing requirements that result from releasing software on a daily basis. This is why Continuous Deployment is a more feasible option at the enterprise level.

Getting started with Continuous Delivery or Continuous Deployment

Building a culture of collaboration is the foundation of DevOps. If you need some guidance about how to put your DevOps infrastructure into place, you can get in touch with one of our Atlassian certified consultants by clicking below.