CI vs CD vs CD — What Are The Key Differences?

When I first started learning about continuous integration and delivery, I had a lot of confusion around the terms and this is probably something a lot of you can relate to. At that time, I haven’t even heard about continuous deployment, so when I did, it just made things worse.

Luckily, I’ve got the chance to meet the world of pipelines. And with that, the fog has been cleared and that made it possible for this article to be born. But what are pipelines? And how it comes into play?

It depends on the context. But since we are talking about software development, a pipeline is a sequence of processes like procedures or commands that are executed in series, one after the other. Sometimes the output of one step is the input for the next. Now before jumping into the details of each continuity, first let’s take a look at what are the steps that makes up a pipeline:

First, code changes made locally are committed and pushed into a central repository. Next, it is checked out by an automated system that builds the project into code pieces that our browsers can understand. Tests are run against it to make sure nothing breaks from our changes. Lastly, it is deployed into its final destination, where end users can reach it.

These are the steps that essentially make up the core of CI/CD. And together, they make up the software development pipeline. Now that pipeline is out of the way, let’s talk about the point of this article.

Get access to 300+ webtips 💌

Level up your skills and master the art of frontend development with bite-sized tutorials.

We don't spam. Unsubscribe anytime.

Get Access to Webtips

---

CI: Continuous Integration#

As the name suggests, continuous integration refers to running integration tests, each time changes are made to your codebase. Whenever you commit and push changes to your repository, the CI system will rebuild your branch and also run all related test cases to verify your new changes won’t break your existing application. To implement CI, there are some prerequisites to be met.

Of course, in order to make your app CI ready, there are some actions you need to take beforehand. The most obvious one is that you can’t build and test your application if there’s no build system or tests to run.

Although it may seem like extra effort —especially if you don’t have any tests—, in return you will gain a lot with CI. The most prominent is that you will ship fewer bugs into production. Automated unit and integration tests are going to catch them before they have a chance to reach production. A good practice, in case a potential bug does reach production despite all your efforts, is to cover them with a test case. This ensures that they won’t cause a regression.

Time spent on manual testing will also be reduced. CI can run hundreds of test cases in a matter of minutes, meaning your testers can focus on important improvements rather than retesting existing functionality, making sure nothing else breaks.

Luckily for us, setting up a simple CI can be done relatively easily, and once it’s configured the only thing left to do is to create some test cases.

Moving a step further and extending our CI set up to have more automation, we get continuous delivery.

Continuous delivery is an extension of continuous integration. It essentially means deploying changes, every time they pass our tests. By this time, you not only automated your build and testing phase, but most of your release process as well. This means you can deploy your application with a click of a button.

With it, the complexity of deployment is reduced, as most of the steps have been automated after building and testing your application. It also means you can have faster iterations and deploy smaller changes. Making it less likely that you introduce a production bug. If you do, however, they are easier to fix as you will know exactly where to look.

Looking to improve your skills? Check out our interactive course to master JavaScript from start to finish.

Remove ads

---

CD: Continuous Deployment

While continuous delivery is an extension of continuous integration, deployment builds on top of delivery. It goes one step further than delivery, as with it, changes are automatically deployed to production without any human intervention. This also means that in order to avoid regressions and other problems to arise, your test suit needs to be top-notch. It determines your release process.

On top of continuous delivery, you’ll gain even faster deployments as everything is handled automagically for every change. You should see your features developed locally in production in a matter of minutes after merging. The risk of releases is also taken further down, as you should strive for deploying in small batches to make troubleshooting easier in case of any problem. With all this continuity, your users will see continuous improvements in your application, instead of seeing big changes every now and then.

To visualize the whole process and the core differences between the three, I would like to close this article with a flow diagram to make you remember it for a lifetime. ⬇️