By Gologic with the collaboration of Alexandre Couëdelo.
Are you fuzzy about the difference between continuous integration, continuous delivery, and continuous deployment?
How many times did you try to explain to someone the difference between these three DevOps practices and ended up googling it to get it right? Maybe you are reading this article because you are in such a situation right now.
At Gologic, this question is often asked to us, and although we have been DevOps expert consultants for several years, understanding the differences and complementarities between these three crucial steps is a good challenge in itself!
So from now, when thinking about those three concepts, we want you to imagine a block tower. One of those towers with a letter on it you may have built as a kid.
The block on top of the tower, continuous deployment is the Holy Graal. It means that your software supply chain is fully automated from development to operation in production. However, several other concepts support continuous deployment.
Each concept builds up on top of the previous one, and if one floor is shaky, you put the entire structure at risk.
In this article, you will understand how continuous integration, continuous delivery, and continuous deployment build on top of each other. Then you will learn how they work so you can apply those concepts to your projects.
Continuous integration, delivery and
Continuous integration is the foundation. Laying this foundation means frequently merging developer code, building or compiling the sources, and packaging the result into an artifact.
Continuous delivery is the intermediate floor. In this stage, you validate an application and decide whether it is ready to go into your production environment. It heavily relies on continuous testing because testing your software is the only way to know if it meets your requirements.
Continuous deployment is at the top of the pyramid. Not only do you build, package and validate your software, but also you automatically send it to a production environment. Continuous deployment can only be achieved with solid monitoring and observability systems; otherwise, it would be like throwing a dart without looking at the target.
Deep dive into continuous integration,
delivery and deployment
Now that you know how each practice stacked on top of each other, let’s dig deeper into each one of them to understand concretely how to apply.
Everything starts with the code produced by developers. The code is versioned, built and packaged into what we called an artifact. The artifact contained all you need to run an application and traces of all the previous stages (called evidence). For instance, you can keep documentation (OpenAPI/Swagger specification), unit test results, test coverage reports, and quality metrics alongside an artifact as evidence.
Continuous integration starts with code and finishes with an artifact.
But the story doesn’t end there. You need to stamp the artifact as “ready for production”. It is common to name the artifact at the stage release candidate. The release candidate will be deployed to a development environment to undergo a series of tests. Once an artifact release candidate is validated, we call it a release. That is to say that the application is ready to go to a production environment.
However, this process of validating an artifact should be as fast and effortless as possible. This is where the concept of continuous testing comes into play. In order to succeed in your continuous delivery, you need to build automated layers of tests to reduce manual validation.
Continuous delivery starts with a release candidate and produces a release.
With a release in hand, you are almost at the end of the story. You could simply deploy the release into production yourself.
You should wonder why not send a release into production automatically? Then let me ask. How confident are you that this deployment will go smoothly? How would you know that something went wrong if you are not there to stare at your logs after pushing the deploy button?
Deploying without human intervention requires a solid trust in the continuous delivery process and a safety net with a reactive monitoring system that alerts you as early as possible if something went wrong with your automated deployment. It is also recommended to have mitigation strategies such as automatic rollback, canary deployment, feature toggling, progressive deployment to lower the blast radius of a failed release.
Continuous deployment starts with a release and deploys it automatically in production.
We want you to remember the block tower image next time you think about continuous integration, continuous delivery, and continuous deployment. It will help you get it right and not forget the critical elements required to move from one to another.
It is crucial to understand the input and output of each practice clearly:
- Continuous integration: takes code and convert it into an artifact.
- Continuous delivery: takes an artifact (release candidate) validates it to turn it into a release. It heavily relies on continuous testing.
- Continuous deployment: takes a release and automatically sends it to production. It heavily relies on monitoring and observability.
Get expert DevOps advice
Do you want to create your automated software deployment chain and speed up your deliveries? Gologic DevOps advisors can help you set up pipelines as code, including continuous development, integration, testing, delivery and deployment (CI/CD). Explore our services or contact us to learn more about our strategic approach.
By Gologic with the collaboration of Alexandre Couëdelo.