CI and CD tools are popular for a good reason. They help us automate the application lifecycle, fully or partially. However, the problem is that, in some cases, we are moving away from the core principles behind the CI and CD processes. Products on the market tend to “bend” the definitions of what CI and CD are so that their products can get “yet another sticker”.
This is an attempt to bring sanity into the insane situation in which everything and nothing are CI and CD.
Let’s start with the basic definitions. I promise I’ll make it simple as I can.
If you have an automated process that starts with a push to a code repository and ends with a release deployed to production without any human intervention, you are doing continuous deployment.
If you have an automated process that starts with a push to a code repository and the only manual action is to confirm the desire to promote a release to production, you are doing continuous delivery.
If you have an automated process that starts with a push to a code repository but ends in a way that manual actions are needed afterward, you are doing continuous integration.
Before we proceed, I need to clarify what pushing to a code repository really means within the context of CI and CD.
If we push changes to a code repository frequently, we can say that the process is continuous. What “frequently” means tends to differ from one organization to another. As a general rule, once a day can be characterized as frequent. Multiple times a day is better, but I will not hold it against you if you do it once a day.
You must not use “tricks” to bend the process to your needs. If you push to a branch that does not trigger CI or CD processes, it does not count. In most cases, only pull requests and merges to the master/production branch count. All the other branches are irrelevant. I do not care what you do inside a branch. The only thing that counts is how frequently you make pull requests and how often you merge to the master branch (unless you’re pushing directly to the master). To make things more complicated, making pull requests counts only if it triggers a CI or a CD pipeline.
Why did I say that only pull requests and merges to the master branch count? The answer is simple. There is no integration without integration. If we work in a separate branch, we do not know whether our code “integrates” with other people’s code until we make a PR or merge to master. Until then, our changes are isolated, so we can discard the word “integration”, just as we could dump the term “continuous” if we do not integrate frequently.
So, if you are making pull requests or pushing to the master branch frequently, you might be doing CI or CD. I cannot say, in that case, if you are really doing CI or CD. Much more is needed beyond “push frequency”. What I can tell, however, is that if you are NOT pushing often, you are neither doing CI nor CD.
You might have everything fully automated. Still, without frequent integration, validation, and packaging, you are not continuous. In such cases, we might be able to say that your process is automated and that you are doing delayed integration or delayed delivery. Now, that does not necessarily mean that you are not doing well. Hey, if you have everything automated, but the processes are NOT running frequently, you are still better than many others.
Nevertheless, there is no reason to call it continuous. Say that you are doing automation. That should be good enough.
Now, if I go back to the CI, CD, and CDP definitions, we can spot a potential issue with at least two of them.
What Is Continuous Deployment?
It is easy to deduce if someone is doing continuous deployment (CDP). Every single push to the master branch is deployed to production without human intervention. If we combine that with the frequency (e.g., once a day), we can say that no one can fake it. Answering this single question allows us to distinguish doers from fakers.
That was the shortest explanation you probably ever heard from anyone. There’s not much more to it, so let’s move on.
What Is Continuous Delivery?
Continuous delivery (CD) does allow people to fake it. One can say, everything is automated, and deployments to production are a push of a button. The problem is that quite a few companies are afraid of pushing that button. They are not comfortable doing it, mostly because they do not trust the process and the validations. So, there is often a separate process that allows only a “clairvoyant” few to press that button. If that’s the case, it is not continuous delivery. You might be doing CI while “faking” that you do CD.
I’m using the word “button” as if it could be any button. It indeed could, but, realistically, the only button that should be allowed to deploy something to production should be “merge to master” one available in pull requests. But, that is a separate subject of GitOps, which I will reserve for some other time.
One of the goals of continuous delivery is to produce artifacts that are deployable to production. It works only if we have full trust in the process and can choose to deliver any release to production, as long as it passed all the steps of a pipeline. There is no difference between continuous delivery and continuous deployment, except in that button. Both are producing artifacts that are deployable to production. The main difference is that, by applying continuous delivery, we are choosing NOT to deploy new releases to production automatically. It is not a technical decision. It is a business choice.
Even though each release could be deployed to production, we might want to wait for the marketing department to start the campaign. We might want to tell users that a new feature is coming before they see it. And so on and so forth. There could be many reasons for continuous delivery instead of deployment, and none of them are technical. In both cases, we have full trust in the process.
Are you still confused? Let me give you a step by step set of instructions on how you can see whether you are doing continuous delivery.
- Find a random person who has nothing to do with your project. If you’re not inspired, you can go to the nearest coffee shop, find a barista who just finished his shift, and tell him that he’s part of a social experiment.
- Open your laptop, log in, and open whichever tool you’re using that shows all the releases and has the “deploy to production” buttons next to each.
- Tell him to deploy any release he wants. If he does not know what “a release” is, tell him that he can press any button. Instruct him to close the laptop when finished.
- Go for a run around the block so that you do not influence him and, more importantly, so that you do not know which button he will click and which release will be deployed.
- Get the laptop without opening it. Go home and spend the rest of the day with your family. Do NOT attempt to check the status of your production cluster.
If you do not get a heart attack during any of those steps, and if you do not end up getting fired, you are doing continuous delivery. You are so confident in the process that you know that any release is indeed deployable to production.
Next, let’s move to continuous integration.
What Is Continuous Integration?
I am not sure what continuous integration really is because, over time, it became whatever anyone wants it to be. Some CI practitioners are only running unit tests. Others are also building artifacts. Some might be deploying apps to preview environments, while others might be running some functional tests after those deployments. That leads us to the main issue of continuous integration. We know where it starts (a push of a change to a code repository), but we do not know where it ends. It’s not really defined what “being integrated” means.
The only thing certain about CI is that the process starts with a push to a code repository and ends somewhere. Where that “somewhere” is differs from one team to another. But that does not matter much. CI is an automated process, after which there are some manual actions.
What matters about CI is that we do not trust the process. We do not trust our automated tests. Otherwise, we would not need to run manual tests afterward.
We all know that the whole lifecycle of an application is a set of repetitive steps. We know that machines are better than humans at executing repetitive tasks. Yet, we do not trust the automation, so we have to take a look. We have to open the page of a Web app to see that it’s really there. We need to fill in some forms. We need to follow some links. We need to send some requests to the backend. We need to do all those things manually because we do not trust the automation we have or are incapable of writing code that does the automation.
If all that makes you feel bad, here’s a bit of reassurance. I can give you the “it’s not you, it’s me” type of explanation one often gets when breaking up. In this context, “me” would be your legacy application that is untestable. It could be the architecture of the app created by someone who does not understand what “deployable frequently” means. It could be a silly separation into silos that prevents any notion of “continuous”. It can be many things, and they might be out of your control.
Did that cheer you up? I hope it did since we are about to remove the word “and” from “CI and CD”, and I need you to be in a “happy place” when we get there.
There Is No “And” In “CI And CD”
I often hear the expression “CI and CD”. That’s just silly. That is a misunderstanding of what continuous delivery is. That somehow assumes that one can do CD without running tests, without building binaries, without making releases, and so on and so forth. It’s as if we can continuously deliver or deploy something without the steps often characterized as CI. So, we can choose to do CI, or CD, or both. That’s not the case. We can do only one. If we are doing CI, we are not doing CD. If we are doing CD, CI is included, so we do not do it as a separate practice.
Continuous integration, delivery, and deployment all start from the same point. Those are all initiated by making a push to a code repository. The difference is only how far to the right the automated process goes. If it stops before generating a release that is deployable to production, it is continuous integration. If it does create such a release, but it does not deploy it to production, it is continuous delivery. If it does everything, including deployments to production, it is continuous deployment.
So, if all the CI steps are available in CD, we can say that continuous integration is a subset of continuous delivery, which is a subset of continuous deployment. As such, there are no CD tools that are not capable of doing CI. However, the opposite is not true. There are indeed CI tools that are not capable of deploying to production.
I must stress out that many tools that are marketed as CD are not doing CD. Argo CD, for example, has CD in its name but is not a stand alone solution, it doesn’t handle testing or all sorts of other things needed for CD. It is in charge of deploying applications while, as I already explained, CD is about the full automation of the application lifecycle.
Now, most CI tools are capable of doing CD. Most are running some form of pipelines that allow us to automate steps in the application lifecycle. The essence of all of them is to provide orchestration of steps. Steps can be anything given that, if everything else fails, one can always execute a Shell script that, for example, does the deployment.
What distinguishes some CI and CD tools from others is not which types of steps they can perform. Anything can be scripted, so any type of a step (including deployments) can be part of a tool that orchestrates automation. The differences are rather in how the tools work, whether they are scalable, how easy they are, how many helper functions they provide, how extensible there are, and so on, and so forth.
I could argue that Codefresh is the tool that is well suited for continuous delivery and, as such, for continuous integration as well. I could say that there are quite a few features that make it stand above the crowd and the best choice we have today. But I will not do that right now. That is reserved for the follow-up post.
Until the next time, please Create A Free Codefresh Account and see how you can take your CI or CD processes to the next level.