Continuous Integration, Continuous Delivery, Continuous Deployment – Application development practices that have been present in many IT projects for several years. Very often described as good DevOps practices.
Many people say they do it in their projects – are you sure? Let’s check what is hidden under these names.
What is Continuous Integration (CI) really?
As the simplest definition, I could give:
It is the practice of frequently merging our work with the work of others into a central repository along with automatic building and testing of the application.
The main goal is to avoid conflicts when integrating our work with the work of others.
It also allows us to find problems and errors much faster, the later found, the more expensive to fix.
The first rule of thumb is to post our changes to the repository frequently, we should do this at least once a day.
If we put our code every week or every 2 weeks – we are not doing it continuously and we shouldn’t call our process continuous integration.
The second basic principle is the automation of repetitive tasks performed every time our code is placed in the main repository. This includes both the automation of building and testing applications, preparation of the artifact, and automation related to e.g. Pull Request.
Without automation in this area, we should also not call our process continuous integration.
As you can see, CI assumes the preparation of a tested application that contains all the latest functionalities automatically for implementation. The next steps, closely related to the implementation, are carried out in the CD process.
The very first thoughts may lead to the conclusion that this is not what we do or what we would like to do in our project. Despite the great popularity, a well-implemented practice of CI is not always a standard, it sometimes happens that the basic rules are not followed or, knowing these rules well, the team consciously does not decide on such practices.
If the processes of building and testing applications in your project are not automated – it’s a pity … but it’s ok, they don’t have to be.
If your code is not often placed in the main repository – a pity … but it’s ok, it doesn’t have to be.
If you say you do CI, but without test automation and frequent integration – that’s not ok, stop saying that 😊
What is Continuous Delivery (CD) really?
You can often come across the description of CI / CD processes as if they were separate or even independent processes.
However, this is not a good description. You cannot realize CD without CI because CD is some kind of CI extension.
In other words, we could say that in order to realize CD we have to do everything we do in CI + something else. It is the remainder of the application lifecycle.
The place where we start the CD process is exactly the same as with the CI. It is common to post code to the main repository.
The end of this process is a ready-to-release application that waits for manual confirmation of its implementation to production environments. It should come down to a business decision when deployed by launching the appropriate deployment with one click or one command.
Unlike the CI process, we do not stop at preparing the code for implementation, but we carry out the entire implementation process.
Continuous Delivery vs Continuous Deployment
Technically speaking, the difference between Continuous Delivery and Continuous Deployment is marginal or absent. The difference is the business decision when the application is deployed to the production environment. This is completely automated in the Continuous Deployment process.
After the code is placed in the repository, the new version of the application is deployed to the production environment without any manual intervention.
The words of truth
As you can see, “Continuous” is one word that repeats over and over again.
It is important to remember that proper implementation of continuous practices requires activities described in another word, the word “frequent”. If you and your team do not put your code in the repository frequently (once a day), you do not really follow the practices of both CI and CD.
Many development teams do not know the definition of CI / CD. Many teams know them and practice them successfully.
Have you ever wondered how it is with you?
Senior Cloud DevOps / Tech Lead in the DevOps team at Inetum Polska. Connected with cloud technologies from the first public accesses to Azure and AWS.
Building the second largest Azure Landing Zone in EMEA, building MVP for the third largest AWS Landing Zone in EMEA.
Currently, it is developing mainly in the area of implementing good DevOps practices. As a consultant, he helps clients build reliable tools and processes to implement applications in the cloud.