CI and CD are two buzzwords that are often used when modern day development practices are talked about. CI stands for Continuous Integration, while CD is often confused with either Continuous Delivery or Continuous Deployment.

Continuous Delivery vs Continuous Deployment

In this article, we will talk about:

• Continuous Integration
• Continuous Delivery
• Continuous Deployment
• Comparison between the above three
• Conclusion

Introduction

CI and CD are two buzzwords that are often used when modern-day development practices are talked about. CI stands for Continuous Integration, while CD is often confused with either Continuous Delivery or Continuous Deployment. Continuous Delivery and Continuous Deployment are quite related, same on many fronts, but they do have their valid differences, which makes both of them what they actually stand for. In this article, we will try to define Continuous Delivery and Continuous Deployment, have a look at their approach diagrammatically and understand the differences between them.

CI – Continuous Integration

• Developers work on their individual branches and merge changes/commits to the main sprint branch as many times a day.
• A build is created as many times after validation via automated unit test cases against the build.

This process is called as Continuous Integration. As the name itself implies –

• Continuous: - Regular or uninterrupted
• Integration: - Combining from various sources

Automated Unit Test Cases play a major role in CI process, the validation against the build happens to make sure that a new change committed by the developers doesn’t break the application. 

CD – Continuous Delivery

Continuous Delivery means that the code is deployable to production, i.e.

• It has passed the automated unit test cases.
• It has been deployed on the staging environment and has passed all the automated integration test cases,
• And can be deployed to production with just a button click whenever the business demands it.

Deployable to production is an important context over here; it means that the code is ready to be deployed to production.

• Theoretically a release can be scheduled daily, weekly, bi-weekly or whenever the client requires.
• But to take advantage of CD, deployment to production should happen as early as possible towards a small sprint/batch to get early feedback from the clients and to overall test the whole process.

A visual representation is as below (Image 1).

Image 1 – Continuous Delivery

From the above image, we can deduce that production deployment is usually controlled by a manual process, which when needed can be done whenever the business needs it. Apart from that, every step is automated.

CD - Continuous Deployment

• Continuous Deployment goes beyond Continuous Delivery by a step, in which there is no human intervention on production deployment and as soon as a feature gets committed, it gets deployed to production after valid CI and staging deployment.
• Only a failed test can break this process.

A visual representation is given below (Image 2).

Image 2 – Continuous Deployment

Continuous Deployment should be the ultimate goal for any company if it doesn’t have constraints on taking the application go live. A prod deployment is often succeeded by a chain of documentation and emails.

• Operations Guide
• Support Guide
• Installation document
• Release emails
• Stakeholder emails
• Official communication
• Marketing and PR on LinkedIn, Twitter and other social media channels
• Success stories

Above are a few of the examples of the documentation and emails which are required to be ready to go once there’s production deployment. Hence Continuous Deployment has to sync a plethora of departments. Even if Continuous Deployment is not possible in every scenario, Continuous Delivery is a must in a DevOps practice. Regular or continuous deliveries instill confidence that a new feature can be delivered to a client whenever it is demanded.

Continuous Delivery! = Continuous Deployment

Continuous Delivery is not equal to Continuous Deployment; often there are confusions amongst the 2 terms. As we have seen above, continuous delivery has a manual component in its pipeline, where in the production deployment is triggered by a button click, whereas continuous deployment is fully automated, a valid change made by the developer gets deployed to the production at that very instant. Continuous Delivery doesn't mean every change is deployed to production ASAP. It means every change is proven to be deployable at any time.

Tabular Comparison

Conclusion

The above article makes a very valid attempt to compare between Continuous Delivery and Continuous Deployment, a discussion between these two is incomplete without the knowledge of Continuous Integration. Continuous Delivery is a must for any DevOps practice. That means Azure DevOps is the combination of various technologies, tools, and best practices to implement CI/CD continuous integration / Continuous Delivery. It's not easy for someone to learn their own and implement, one can take advantage of various DevOps Certification Training or DevOps online courses to leverage with DevOps skills, gain the confidence to work in Azure DevOps. 

Take our free skill tests to evaluate your skill!

In less than 5 minutes, with our skill test, you can identify your knowledge gaps and strengths.

GET TEST NOW