Today, you often hear the words Continuous Integration, Continuous Delivery, Continuous Deployment, and CI/CD interchanged in conversation. In this article, we will take a closer look at their differences, and what truly makes these schemes effective.

Identifying Continuous Integration, Delivery, and Deployment

In Continuous Integration, developers work by versioning their code in a repository. There is a Continuous Integration server that takes those changes, builds the application, runs tests and determines if the build is “broken” or “stable,” at which point it notifies the developers.

Continuous Delivery goes hand in hand with a DevOps culture. It is not just “Continuous Integration” (which is a task that could be done by the development team, without participation or influence on anyone else), but rather assists the whole process of the construction and delivery of software so that we are frequently delivering new value to users and customers. Optimizations to the process both include and impact the business, development and operations, and hence, the relationship with DevOps.

At Abstracta, we work more and more with clients who already have this methodology in place. The benefits in productivity and quality with which it is delivered to the user are remarkable. However, perhaps more noticeable than anything is the tranquility that comes with the changes. A good way to summarize Continuous Integration would be that it seeks to reduce risk and increase confidence in the delivery process.

I wanted to leave here some notes about my own understanding of what marks the difference between Continuous Integration, Delivery and Deployment, written in simple terms:

Continuous Integration

Continuous Integration means the ALL code is frequently merged to the stable codebase (at least once per day) on a specific server. In this way, a stable code repository is maintained so that anyone can begin to work on a change. The build is automated, along with various automatic checks, such as code quality review, unit testing, etc. In essence, it helps avoid the “fun” situation when two developers start from the same code base and work separately on it for a month, then try to combine their changes. It’s a headache!

Continuous Delivery

The main objective here is to release new versions of the software to the client as often as possible. It’s designed upon Continuous Integration. An executable version of the system is frequently built with the latest integrated code. If this version passes the automated checks, it finishes performing an installation in a development or test environment. Often, these versions are automatically tested and “manually” delivered to the user. There is a lot of great information about continuous delivery on this site by Jez Humble.

Continuous Deployment

Continuous Deployment takes it a step further. If the new code passes all the automated tests in the test environment, then it goes directly into production. The deployment process is well-oiled, releasing gradually. If any user has a problem, then rollback and feedback transfer back to the developer to correct the problem.

The difference between Continuous Delivery and Continuous Deployment is the fact that in Continuous Delivery, someone has to deploy the code into production “manually”. Sure, it’s mostly automated with just a simple click or execution of a command, but the important thing is that someone has to make the decision. In Continuous Deployment, this is automatic. Every new line that passes all the automatic checks goes straight to the users (you often hear about companies such as Facebook or Google doing this).

A little while ago I taught a DevOps and Continuous Delivery course with Nico Paez, who made the following comment:

“If it hurts, you have to do it more often. We’re going to get used to the pain, or we’ll do something to stop it from hurting.”

Delivery Pipeline: From Idea to User Happiness

There’s a pipeline from the initial idea or requirement to the user’s satisfaction with the functionality in the system. At different points in that pipeline, we should be welcoming feedback to correct any deviation from what the client wants as soon as possible. It is worth clarifying that (as I see it), it is not enough to evaluate that pipeline the moment the user receives the software for the first time. I think we must also look at the back and forth that can be generated. This is why, in this process, it’s just as important to take measures of how our system performs in the hands of users to continue the cycle of continuous improvement based on the feedback that is obtained when they use it.

To increase productivity and to reduce the time to market )that is, the time from when the idea is born until it reaches the happy hands of the customer), I want to mention two things I have heard and discussed lately:

From my conversations with Enrique Almeida about CI/CD, he commented: “The big change is to start thinking about ALL the life processes of an application instead of optimizing by parts. It brings great changes in the way of working, but there are many opportunities for improvement in productivity and quality.” 

Karen Johnson commented in a podcast: “CI/CD is not just about going faster, it is also about asking other questions. This allows us to establish timely conversations around the software creation process. It is not a fast delivery just because, but for those who have the vision of a tester, it provides spaces where we can ask more questions, resulting in optimizations for the process and quality improvements.”

We have to ask other questions by looking at the whole and optimizing not only the parts, but the overall process. CI/CD poses to have an optimized process to get feedback as soon as possible, detect the error early and correct it before it spreads to the client’s hands.

—

Thanks, Federico Toledo, for sharing with us the most important aspects of these three related concepts. And thanks Abstracta, for participating with this post in our Blog!