Last week we discussed the process of continuous integration (CI) and how it’s becoming increasingly vital for software development.

CI is the first half of a development process known as CICD. It’s sometimes debated whether CD stands for ‘continuous delivery’ or ‘continuous deployment’. These terms are often assumed to be analogous – and they very nearly are – but there are slight nuances between them. To explain the differences, we must first define the terms.

Continuous integration

Continuous integration is the practice of frequently updating the master code repository throughout development. The developer’s feature branch of the code is integrated into the master frequently throughout the day, and the step between development and build/testing is automated.

Continuous delivery

A continuous delivery pipeline includes the CI process, but also automates the delivery. Once the code has been integrated with the master, a continuous delivery process commits it to be built and tested, and made ready for productions. If the automated tests are accepted the feature is often delivered to a staging environment for manual testing. Continuous delivery means that every code change is ready and waiting to be deployed at any time, but hasn’t actually been deployed yet.

Continuous deployment

Continuous deployment automates all of the steps in the process between the code being committed to the feature being deployed in the live environment. The integration at the development stage is automated, as is the build, testing, acceptance, staging, more testing, more acceptance, and then production. This way, the code is released to production as soon as it is has passed the automated tests.

What is the difference between continuous delivery and continuous deployment?

The difference between continuous delivery and continuous development comes in the step between staging and production. In a continuous delivery environment, the step between acceptance and production is a manual decision. Continuous delivery automates everything up to that point but says that, for whatever reason, there must be a manual decision/input between automated acceptance and production.

In a business scenario, this manual acceptance is often the result of a period of testing on a QA platform. The automated process is stopped just before production to give a QA engineer or developer the opportunity to manually test the feature before it is released. In continuous deployment this manual testing phase is automated, and that’s the main difference. Continuous delivery means that the decision on whether or not to release can be put in the hands of the business, not the developer. Extra testing is one reason the business could choose to stall the release, but they could also stall it for other reasons: release dates, variant testing, etc.

The reason behind choosing one or the other comes down to the business’ confidence in their developers, and in their testing. To commit to a continuous deployment pipeline the business must be 100% confident that no errors or bugs will make it through to the live environment.

If they trust that their developers have coded perfectly, and they trust that the automated tests have found no bugs, only then should they commit to a continuous deployment pipeline. If they can’t be 100% confident then continuous deployment is not appropriate.

If they are only 95% certain that everything is going to be okay when it is produced to live, then continuous delivery is the right choice, because it gives the business an opportunity to conduct manual reviews and tests before release.

Although the fundamental difference is small, the continuous deployment pipeline does not just change the production process, it changes the entire development. The developer will have to code in a completely different way to fit a continuous deployment pipeline than to fit a continuous delivery pipeline. This different methodology during coding is another thing the business would have to consider.

The benefits

In a CD process (either of them) the main benefit is time saved. The constant automation saves time all the way through the process. The automation saves time for developers and testers, making them more productive and efficient. It also improves time to market, which means customer feedback is quicker, and a higher quality product can be developed faster. This process also results in fewer risks on release.

For fast, secure, and reliable hosting solutions for your projects, visit the Fasthosts website.