CI and CD are two important terms that are often used when people talk about DevOps and Automation.
Ever wondered about what is Continuous Integration (CI) or Continuous Delivery (CD)? What is the difference between Continuous Deployment and Continuous Delivery?
In this article, we will answer these questions, and learn all about these practices and how they may or may not work for your projects.
Introduction
CI stands for Continuous Integration, that focuses on streamlining builds and testing process of an application.
CD stands for Continuous Deployment or Continuous Delivery, depending on how the processes are defined. Both of these practices have a lot of similarities, with a very significant difference.
Let's understand each of these practices in detail now.
What is Continuous Integration (CI)?
In simple terms, CI is the process of merging all the Developer code changes to a single shared main branch as often as possible, frequently.
Developers merge their code changes, many times a day, to the remote Git Repository's main branch. These code changes are then verified and validated by using automation to create builds and run tests on the created builds.
For those who follow the Waterfall methodology, this practice might sound hectic and complex. On the contrary, at any given time, the code changes being pushed are smaller. Therefore, it is easier to debug and resolve if any issues arise.
So, the new code changes being pushed are built, integrated and tested in a few minutes, providing immediate feedback to the developer about the code status and any issues.
Continuous Integration ensures that the application is not broken whenever new commits from all the developers are integrated into the Release branch of the Repository, as they are all tested well in advance.
What is Continuous Delivery (CD)?
Continuous Delivery is the practice where the code changes are released frequently in shorter cycles to customers, quickly and reliably.
In continuation with Automated Testing in CI, the application release process is completely automated so that the code changes can be deployed incrementally at any point of time by just clicking a button (manual trigger).
Generally, shorter release cycles are recommended. Depending on the size of the project, and business requirements, you can configure daily, weekly, fortnightly release schedules.
The shorter the release cycle, the easier it is to troubleshoot in case of any issue after deployment onto a Production environment.
What is Continuous Deployment (CD)?
Continuous Delivery without a manual trigger is Continuous Deployment.
In Continuous Deployment, every code change is directly released to customers without any manual intervention if it successfully passes all the stages of your CI/CD pipeline.
So, if there are no failures in any pipeline tests, every code change is available to the customers immediately. No more Release days!
It is very useful to improve the feedback loop with your customers. Developers can see their changes Go-Live in a few minutes, providing them more time to focus on building better quality applications.
This level of automation is made possible by a combination of several tools and processes that work together to verify and push the code changes to production.
Once the developer pushes the new code change, it is automatically built, integrated, tested, and directly deployed to the production environment.
What is the difference between Continuous Delivery and Continuous Deployment?
Continuous Delivery involves manual triggers and human decision-making around what and when to release to the customers. This forms the basis of the difference between Continuous Delivery and Continuous Deployment.
In Continuous Deployment, every code change goes through automated tests and verifications, and if everything is passed successfully, a working version of the application is automatically pushed to production.
Naturally, a lot depends on the quality and efficiency of the test suite and the CI/CD pipeline. With Continuous Deployment, teams can have multiple application deployments on any given day.
Also, Continuous Delivery usually involves a Production-like Staging environment with a mandatory time lag before the final release. This time is used to manually review and accept the code changes before they are released to Production.
In contrast, Continuous Deployment doesn't generally have any Staging environment for code changes to be manually reviewed or accepted. This is mainly because all the code changes are already verified early in the development and passed through all the stages of the pipeline.
How to go from Continuous Integration to Continuous Deployment?
If you are beginning a new project with just a few contributors, it might be easy to directly deploy every code change to production, i.e., Continuous Deployment. You can start automating your deployment process and directly release your code changes for Alpha and Beta Releases to production.
Later, before you begin adding users/customers, start adding test jobs to the CI/CD pipeline, making sure the code coverage is adequate, as you build your application. By the time you gain more users, you will have an efficient and stable CI/CD pipeline where all the new code changes are well tested before they are released to production automatically.
If you already have an existing application with users, you should start adopting these practices slowly. You can begin with Continuous Integration and Continuous Delivery. Review your processes regularly and iterate the CI/CD pipelines based on customer feedback and business requirements.
Then, slowly start including basic Unit tests that get executed automatically, complex end-to-end functional tests need not be a priority in the early phases. Instead, focus on automating your deployments as much as possible and get to a stage where application deployments to your Staging or Pre-Prod environments are done automatically.
The reason you need to focus more on automating deployments is that, in most of the cases, a lot of time and effort is spent on actually deploying the code changes to your target environments. Once, you achieve Deployment automation, you can gradually shift your focus again on improving your automated tests.
But, make sure the rest of the organization like Documentation, Sales, Support and Marketing teams are ready to handle the Releases being deployed frequently. These teams will need to revamp and adapt to the new automated processes, without causing any noticeable impact on the customers.
Conclusion
Whether your organization follows one of these practices or something else altogether, the key requirement to improve product quality and delivery efficiency is by enabling automation as much as possible in the delivery pipeline. This will ensure sustainable and reliable product delivery to your customers.
The goal is to develop a high-level of automation in the application delivery, without giving up on the visibility and control of the overall process.
