Problem Statement

I received an interesting question on one of my articles on DevOps. The gist of the question was primarily on the scope of CI/CD and the difference between Continuous Delivery & Continuous Deployment. I thought this was a nice opportunity to put down my thoughts around this in a quick blog post.

Continuous Integration is a development practice which encourages developers to check in code changes to source control as frequently as possible. Since the code is checked in and integrated more often in smaller pieces, it is easier to identify and resolve issues at an earlier stage.

Every code commit triggers an automated build in a separate CI server and executes the unit and integration tests. Code Quality is maintained since any build which has failing tests are not allowed to get checked in to source control repository.

Continuous Delivery goes one step further than Continuous Integration to automate the software release process, where code is deployed to environments and is prepared for Production release.

In short, the goal of Continuous Delivery is to create a code version which is ready to be deployed to Production at any time.

The decision to go to Production is a business one and is not a technical dependency. There are lot of products/organizations where you can deploy to Production only after getting an approval from the Business stakeholders. Most of the times there is also a formal User Acceptance Testing in place where the Business Users perform a round of testing in the Staging environment. Only after getting the thumbs up from them, the code is deployed to Production environment.

We have been using Feature Flags in our applications with great success. This allows us to release a product version to Production with unfinished features. Once the feature development is complete, the code is pushed to Production and then the feature flag in turned on.

If you are using Feature Flags in your application, you can achieve Continuous Deployment by deploying the code all the way to Production with the Feature Flag turned off and with no manual intervention.

In the current project I am working on, once we push changes to Source Control and if it passes the Automated Tests (Unit Tests, Integration Tests, End-to-End Tests) and SonarQube Quality Gates – the code is deployed all the way to Production. This is a sign of a fully matured CI/CD pipeline with complete automation. With approx 97% unit test code coverage, the strictest SonarQube Quality Gates in place and the automated test suite, we have high confidence in our code to be deployed to Production, if it passes all these steps.

Keeping the above practices in mind, I would define Continuous Deployment as the next step of Continuous Delivery, where every code commit that passes the Automated Tests and SonarQube Quality Gates is automatically deployed to Production without any manual intervention.

Conclusion

To wrap up this article, we can reiterate the fact that Continuous Delivery makes your code release ready, but the decision to deploy to Production is manual – dependent upon Business approval. They decide when the code is pushed to Production. However with Continuous Deployment, the pipeline is completely automated all the way till Production deployment, without any manual action.

To deliver high quality Business features to Customers faster, having Continuous Delivery is a must. Continuous Deployment is a nice to have.

My colleague Robb Schiefer wrote an excellent article on Continuous Delivery and how we implemented it within our organization. I would highly recommend you to check it out — Continuous Delivery…Incrementally

Categories: DevOps, SQL Server, Test Automation