Continuous Delivery vs. Continuous Deployment vs. Continuous Integration

Continuous Delivery vs. Deployment is an important issue because the two approaches may seem similar in many ways, but in fact they are different. It is also very important to talk about Continuous Integration. Indeed, Continuous Integration is essential to ensure the seamlessness of Continuous Delivery.

Continuous Delivery

With Continuous Delivery, software is developed in such a way that it can be released to the production environment at any time. This process requires automated quality assurance test environments where new builds are automatically tested. If the code passes all tests, human approval is required for release. 

Continuous Deployment

In contrast, Continuous Deployment goes one step further and eliminates manual approval. Here, tests and developers are trusted so much that deployment to production environments happens automatically as soon as the tests have run successfully.

Continuous deployment is an excellent way to speed up the feedback cycle with users and reduce pressure on the team, as there are no more release dates. Developers can focus on building the software.

Continuous Integration

This process allows developers to communicate effectively about changes made to the project.

Developers often work from a master branch of code, but when different developers combine their changes, functional problems and bugs can occur. Continuous integration addresses this by having each developer merge their code changes into the central database at least once a day. Automated build tests are run during new updates, ensuring that changes remain compatible with the master branch.

WORTH KNOWING: Continuous integration, delivery and deployment are collectively referred to as continuous software development and are linked to Agile and DevOps methodologies.

How do these practices relate to each other?

Simply put, continuous integration is part of both continuous delivery and continuous deployment. And continuous deployment is like continuous delivery, except that the releases are automatic.

For new projects, without users

When starting a new project without users, it can be easier to deploy all commits to the production environment. First, we can automate the deployments and release the alpha version to the production environment without users. Then we can gradually strengthen the testing culture and increase code coverage during the build of the application. And by the time we are ready to accept users, we will have an excellent continuous deployment process where all new changes are tested before release.

For existing users

Once we have users, we need to move much more slowly and start with continuous integration and continuous delivery first. 

It is worth starting with basic unit tests that run automatically, no need to run complex end-to-end tests. Instead, try to automate deployments as soon as possible and get to the stage where deployments to a staging environment are automatic. 

Automatic deployments allow us to focus on improving tests, rather than stopping from time to time to align releases.

Daily software releases

If software is released daily, we can move to continuous deployment. However, it is important to make sure that the rest of the organisation is ready: documentation, support, marketing, etc. These functions need to adapt to the new release schedule and it is important not to miss significant changes that may affect users.