DevOps – Difference between Continuous Integration, Delivery, and Deployment

configBlog, ConfigLeave a Comment

Photo by diwou from pixabay.com
In configuration file hell? Take a look at Config, the easiest way to manage your application configuration across all your servers and environments.

In DevOps times, the terms we hear most today are:
Continuous Integration
Continuous Delivery
Continuous Deployment

Like every fashion term, we often hear distorted explanations of what each practice is and what it is for.

Well, let’s detail what each of the processes is. I will try to be objective and simple in explanation.

Continuous Integration

A frequent confusion is equating continuous delivery with continuous integration. This view is a big misconception. Continuous integration is the practice of integrating and testing a new code with the existing code base, and is a necessary condition for the continuous delivery process to happen in the right way.

It is the process of merging your new code with a branch. The idea here is to test your code as soon as possible to identify problems early.

Most of the work is done through automated testing, and this technique requires a unit testing framework. Usually there is a build server for these tests, so developers can continue the work while the tests are being run.

Continuous Delivery

This is where the biggest confusion appears. People sometimes use the terms of continuous delivery and continuous deployment in turn. The two practices are not the same thing. Continuous Delivery is a set of practices that aims to ensure that the new code can be deployed in the production environment at any time, and continuous deployment takes a step further.

In the practice of continuous delivery we try to send the code to an environment, which can be DEV, STAGE or PROD, once the developer feels the code is ready to send. But in this part of the process the idea is that the code is being delivered to a user base, understood by user base, Testers / QA. This is similar to continuous integration, but we can now scale the Behavior Tests (BDD) to test business logic or even visual tests.

Does it mean that after this delivery to the first users means that it should go to production or even stage? No! It means that you are delivering to this first user base and point. This may only mean that delivery is being made to Code Review.

Continuous Deployment

After all, what is the furthest point that Continuous Deployment addresses and what makes it so different from delivery practice? This part of the process addresses the automation of the publishing process in the production environment as soon as you are sure that the code has passed all the tests and is ready to be published. The idea is to deliver business value as quickly as possible and not accumulate new code on stage. That is, if the code went through the integration process that is responsible for integration tests or unit tests, and also was advancing in the delivery process with manual, visual and behavioral tests, then enters the deployment phase that is responsible for publishing the code in production in an automated way.

At this stage of the process it is assumed that all tests have been done, and only the issue of automated publication in the production environment will be addressed.

It is assumed that the production environment is stable, that everything has been tested and that this process should be as simple as pushing a button and that it should be possible for anyone to do it.

That is, for Continuous Deployment, you necessarily need to have Continuous Integration and Continuous Delivery running as part of your routine.

Leave a Reply

Your email address will not be published. Required fields are marked *