Modern software engineers usually have a general idea of what Continuous Integration, Continuous Delivery, and Continuous Deployment refer to in practice. However, the minute differences between these CI/CD processes often get confused. Below, we’ll define the nuances between these concepts, and look at the advantages and disadvantages of such continuous development approaches.

CI vs CD vs CD 101

Writers and developers alike tend to throw around “CI/CD” in a pretty general way to describe agile release strategies. Things are a bit fuzzy, though, because CD often refers to Continuous Delivery and Continuous Deployment. You know that differentiating between related terms is going to be difficult when you can’t even use acronyms to refer to them without them overlapping…

Although the terms are often used interchangeably, most people are referring to Continuous Delivery when they refer to CD. That’s simply because Continuous Delivery came into prominence slightly earlier than Continuous Deployment. They may have the same prefix, but these processes have some pretty clear differences.

First off, let’s look at Continuous Integration.

Continuous Integration

In basic terms, Continuous Integration involves the automation of code changes made by multiple contributors being integrated into a single project. It doesn’t, however, necessarily affect the process of deployment.

As opposed to the “old ways”, CI focuses on an agile approach that allows for automatic testing and validation. This stands in stark contrast to the waterfall model, in which every phase of integration relied on deliverables from the previous one. The result of CI is a more speedy and iterative approach.

A CI process usually involves using a dedicated tool like Jenkins or Travis. What is it about male first names when it comes to branding CI tools?

Continuous Integration Example

Several eCommerce store engineers are collaborating on a payment microservice. With CI, they are all independently able to push their code continuously into a branch in a shared Github repo. As they work, code can be tested (and iterated on) using a Jenkins server.

Continuous Delivery

Continuous Delivery goes beyond CI because it refers to how code is tested, staged, and deployed. Automating these processes requires different tools, so it is not as simple as just setting up a CI server using something like Jenkins.

With (what some would call) the original CD, deployments are scheduled at rapid intervals, and there’s a final manual approval process before a release occurs. Ideally, deployment takes place regularly as code releases are scheduled. In other words, the act of deployment itself is not automated.

Continuous Delivery Example

The eCommerce store, where the above engineers are all working, sets a weekly production push timeline. On Wednesdays at 5 pm, all new builds are published to the production applications, and engineers can see how everything has come together.

Continuous Deployment

In Continuous Deployment, on the other hand, automated testing is used to validate the accuracy and performance of code changes automatically. If code passes, it is immediately deployed to a production environment automatically.

Proper testing and validation are always essential, but Continuous Deployment takes automation to a whole new level. Some teams use a Continuous Delivery/Deployment hybrid, automating deployment to a test server but retaining the final say over what goes live.

That’s understandable because errors are only one step away from being pushed live in Continuous Deployment…even if that should never happen, as long as everything has been set up correctly.

Continuous Deployment Example

Responding to user feedback more quickly becomes vital for the eCommerce store to remain competitive. Engineers continue to work on various parts of the payment microservice, but continually publish code. As long as their code passes, it is pushed to production instantaneously instead of waiting for the weekly Wednesday release.

The Right Tool For The Job

All of the above processes are closely related. However, it’s important to differentiate between them to avoid confusion. For example, take someone working on a Continuous Delivery project that has been mislabelled as Continuous Deployment. They may not even realize that they need to take that final step of manually approving changes.

Describing a process is “CI/CD” is a bit like describing something as “cloud.” Does that mean the public cloud? Private? Hybrid? Multi-cloud? The more specific you can be about a process, the better.

Another big difference between CI, CDel and CDep is the range of tools required for implementation. Setting up CI processes could be as simple as using Git for source control and a CI server like Jenkins or Bamboo.

It’s beyond this stage that things start to get complicated and, as we know, complicated can mean expensive. For example, in the case of CDel, more tools are needed for release automation and build automation, along with integration tests, functional tests, and acceptance tests.

By the time you get to CDep, you may need to start thinking about yet more tools like Octopus Deploy or DeployBot for automation of deployment processes. But there’s a possibility that this may not be the case for long…

With a ton of automation plugins available, allowing for use as a continuous delivery hub, Jenkins seems to be moving towards positioning itself as a one-stop CI/CDel/CDep solution. The only downside to this is that choosing the correct plugins and setting them up requires some detailed knowledge of these processes.

Alternatively, Amazon has begun positioning AWS as a CI/CD solution, but it remains to be seen how aggressively they’ll pursue extending this to Continuous Deployment.

Final Thoughts

Some argue that “the Continuouses” are the future of development. 17% of developers surveyed told Statista back in 2018 that “my entire company has fully embraced DevOps,” and CI/CD processes are closely tied to DevOps.

In 2020, developer appetite for automation and agility (from APIs to DevOps) seems insatiable. It feels like “the next big thing.” On the other hand, there’s the possibility that Continuous processes could reach a peak and fade away.

In the context of APIs, Continuous processes can even seem a little scary: it’s not enough for a connected product to pass tests that check everything is working properly before deployment, it’s also important that it doesn’t break other services that are synced up with it.

Counterintuitively, automation is an ongoing process. CI and the CDs definitely have value – they foster small, simpler code changes and make fault isolation quicker, to name a couple – but they still require plenty of tweaking and monitoring. The implementation may be intensive, but, for some companies, that initial outlay will prove to be worth its gold weight.