Continuous Integration vs Continuous Delivery vs Continuous Deployment
Continuous Integration, Continuous Delivery or Continuous Deployment? There is always a great misunderstanding of these terms out there! Let's clarify them in only 5 minutes.
Continuous Integration
Continuous Integration (CI) is a development practice from Extreme Programming that requires developers to integrate code into a mainline as often as possible, at least once a day, and each check-in is then verified by an automated build that compiles the code and runs the suite of automated tests against it, allowing teams to detect problems early.
In the Git context, the mainline often turns out to be the master branch and each check-in is a new commit that emerges into the remote repository.
Implementing continuous integration provides several benefits:
• Merge hell, that is, endless merge conflicts while merging code into the mainline, is avoided because the code should be integrated to the mainline as often as possible (at least once a day).
• Allows detecting errors quickly as automated tests run on every single commit that checks-in the remote repository. Hence, fewer bugs get shipped to production.
• When an error is detected, it’s much easier to fix because the amount of code involved in each commit is much smaller.
• Promotes human communication earlier when merge conflicts occur. People can sit together and understand how their codes are actually influencing the other’s code.
• Building the release is easy as all integration issues have been solved early.
However, everything comes at a price. To implement continuous integration, the development team must understand that:
• Tasks should be split as small as possible in the planning stage because the code should be developed (including automated tests) and integrated into the mainline as often as possible, at least once a day.
• Automated tests should be present for each new feature, improvement or bug fix. They will ensure that a change (even a small one) is not breaking any other part of the system.
The second part of the definition states that "each check-in is then verified by an automated build that compiles the code and runs the suite of automated tests". In order to run automated tests on every single commit that emerges into the remote repository mainline, the team will need to set up a Continuous Integration server. The essential purpose of the CI server is to run automated tests on every new commit that emerges into the remote repository mainline, but it is actually capable of doing much more than that, such as issuing custom notifications when a test or build fail, triggering releases generation, triggering deployments to a specific environments, and so on. A well-known CI server is Jenkins, a leading open source CI server written in Java that provides hundreds of plugins to support building, deploying and automating any project.
A smooth Continuous Integration flow will ensure that the mainline is always in a deployable state. Continuous Integration and others Extreme Programming practices such as Automated Tests, Pair Programming, Test Driven Development, Refactoring, and Simple Design are all great contributors to the quality of an application code. If your team doesn't care for these (and others) techniques, it's very likely that you cannot ensure that the code actually works as intended. So, how could you have an automated deployment flow if you have no idea whether the code being delivered works or not? That's the reason why Continuous Integration is a requirement for implementing both Continuous Delivery and Continuous Deployment.
Continuous Delivery
I really like Jezz Humble’s definition of continuous delivery:
Continuous Delivery is the ability to get changes of all types; including new features, configuration changes, bug fixes and experiments into production, or into the hands of users, safely and quickly in a sustainable way.
In other words, when your team really implements continuous delivery what it actually means that the mainline is always in a deployable state, and one could decide to deploy it to production at any time at the touch of a button. This in turns is only possible because when this button is touched, an automated pipeline (a set of automated steps that your code changes goes through until it is finally deployed to production) is triggered. The key element for achieving continuous delivery is automation!
Well, if you can deploy to production at any time, the question is: when is it the right time? Of course, the answer may vary depending on your business requirements, but the truth is that if you want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.
Continuous Deployment
Continuous deployment is very similar to continuous delivery, but it takes even one step further regarding automation. In continuous delivery, every change pushed to the main repository is ready to be deployed to production, but starting this process still requires human interaction. In continuous deployment, the deployment to production is automatically triggered for every change that passes the test suite.
As in continuous deployment every change that passes the test suite is deployed to production, it heavily relies on Feature Flags to release features to end users.
--------
This article was based on the contents of my book Continuous Delivery for Java Apps: Build a CD Pipeline Step by Step Using Kubernetes, Docker, Vagrant, Jenkins, Spring, Maven, and Artifactory. Click on the link and download the free book sample (110 free pages!) to learn more about Agile, Continuous Delivery, Scrum, Automated Tests (unit, integration, acceptance and performance tests), Feature Branch, Feature Flags, A/B Tests, Canary Releases, Apache Maven, Artifactory, Docker, Kubernetes and more!
This book will guide you through the implementation of the real-world Continuous Delivery using top-notch technologies that are in high demand by the best companies around the world. Instead of finishing this book thinking "I know what Continuous Delivery is, but I have no idea how to implement it", you will end up with your machine set up with a Kubernetes cluster running Jenkins Pipelines in a distributed and scalable fashion (each Pipeline run on a new Jenkins slave dynamically allocated as a Kubernetes pod) to test (unit, integration, acceptance, performance and smoke tests), build (with Maven), release (to Artifactory), distribute (to Docker Hub) and deploy (on Kubernetes) a Spring Boot application to testing, staging and production environments implementing the Canary Release deployment pattern to mitigate risks.
This is the book I wish I had found when I was learning about Continuous Delivery; that's why I wrote it. It will bring to you years of experience implementing Continuous Delivery in many different projects.
Hi Brad! Thanks for commenting on my post and for your feedback. I'm going to answer each part of your comment. I hope it helps! :) "If the primary purpose of continuous *delivery* is getting working software into the hands of users in order to get feedback ("validated learning")" I would say that this is closer to the primary purpose of Scrum than Continuous Delivery. Please read carefully the Continuous Delivery's definition again and note it states that it's the ability to GET CHANGES INTO PRODUCTION (or into the hands of users) SAFELY AND QUICKLY IN A SUSTAINABLE WAY. The primary purpose of Continuous Delivery is what is described in capital letters rather than getting feedback from users. In fact, getting feedback from users early is just a consequence (a benefit, by the way) of Continuous Delivery. We primarily do Continuous Delivery because it takes away the complexity of deploying software to production, which is something hard, boring and error-prone especially if it's done by humans, and not to get feedback from users. BECAUSE in Continuous Delivery deploying software is much simpler as it relies on a fully automated flow, we can even do it several times a day by releasing small batches, which makes it easier to find and fix a possible bug delivered to production. One of the CONSEQUENCES of this is that we can get feedback from users early, but it's not the primary purpose. "I don't think it's clear from the diagram that deploying to staging implies getting feedback from business users. It may certainly imply getting stakeholder feedback, but very often, stakeholders may be strictly internal (not actual users/customers, and not necessarily a suitable proxy for real users/customers)." The point here is: What's the definition/purpose of a staging environment? The staging environment is by definition an environment which is NOT intended to end users (like customers buying products for real), but only for testing purposes (manual and automated tests) and validation by stakeholders. As it's a production mirror (same hardware, same software, same settings), the chances to get a bug in staging are much higher than in the testing environment or in the developers' machine. However, as mentioned before, it's NOT supposed to be accessed by end users. Therefore, the diagram is correct when it shows the staging step standing "behind" production rather than "beside". "On the other hand, I could automatically deploy all the way thru to a "production" *environment*, but the production environment may not yet be considered "live" yet, or not full distribution (e.g., accessible only to a limited set of users/servers/sites). Such may be the case with so called alpha/beta or even canary releases. I can have a so called "controlled rollout" (rather than full/volume deployment) where it is "live" in production, but for early access validation (and not yet deployed "live" to *all* servers or sites or populations of users)." Yes, you are correct. An important point to clarify (which by the way is a dedicated chapter in my book Continuous Delivery for Java Apps and can be viewed for free in the sample book) is the difference between Deployed and Released. I will just copy it from my book and paste here: --- Deployed: A technical concern that applies in the domain of the team and means the product is introduced in a chosen environment (testing, staging, production, and so on). Released: A business term that defines functionality being available to an end user. Note that deployed doesn't necessarily mean released. That's because you can deploy code to production that is not active for the end user. In other words, although the code is indeed in production, the feature behind it is not visible to the end user. This mechanism is called Feature Flag and we will discuss it later in this book. --- However, you perform Canary Releases in your production environment rather than staging. As mentioned before, staging is used for testing purposes and stakeholders validation. "Is your intent to convey that the most significant/fundamental difference between continuous delivery and continuous deployment be the extent of automation? (i.e., fully automated with no manual intervention/authorization required?)" Yes, that's the fundamental difference between continuous delivery and continuous deployment.
Brad Appleton ::: good points. I am just getting my feet wet in this terminology and it sure seems that too many teams are not clear why CI/CD is a best fit for them - except for that it is a cool new trend.
I like the article. And I like the definition used for Continuous Delivery (Jez Humble's). I worry the corresponding diagram (and subsequent description) doesn't do justice to the key difference in meaning between the Delivery versus Deployment aspect... If the primary purpose of continuous *delivery* is getting working software into the hands of users in order to get feedback ("validated learning"), I don't think it's clear from the diagram that deploying to staging implies getting feedback from business users. It may certainly imply getting stakeholder feedback, but very often, stakeholders may be strictly internal (not actual users/customers, and not necessarily a suitable proxy for real users/customers). On the other hand, I could automatically deploy all the way thru to a "production" *environment*, but the production environment may not yet be considered "live" yet, or not full distribution (e.g., accessible only to a limited set of users/servers/sites). Such may be the case with so called alpha/beta or even canary releases. I can have a so called "controlled rollout" (rather than full/volume deployment) where it is "live" in production, but for early access validation (and not yet deployed "live" to *all* servers or sites or populations of users). Is your intent to convey that the most significant/fundamental difference between continuous delivery and continuous deployment be the extent of automation? (i.e., fully automated with no manual intervention/authorization required?) Or is it the extent of *real* user/customer validation & feedback? and does that relate to whether or not the software is considered deployed not just "in production", but that it is *live* and accessible (for full production use) to the full set of users/servers/sites?