Over the past few years Continuous Integration, Continuous Delivery and Continuous Deployment have been a part of daily software vocabulary. What does it really mean, and what is the difference between continuous delivery, continuous deployment and continuous integration? Keep reading for some perspective.
Continuous Integration is a core technique where everyone commits every day and code is integrated early and often. This improves frequency and reduces difficulty. Continuous integration can really mean one of two things, depending on the context.
In the narrower sense, continuous integration refers to the work done by a continuous integration server, such as Jenkins or Bamboo. A continuous integration server automatically tests code written by individual developers to make sure it can be merged into the main code base. By automating this process, continuous integration servers help developers to write and test small chunks of code on an ongoing basis, which minimizes the risk that a code change could cause serious problems and force developers to revert their application to an earlier state.
In a broader sense, continuous integration means the constant integration of changes to an application at all stages of the delivery chain. This includes but is not limited to the automated integration testing and code merging performed by an integration server. In this broader definition, continuous integration can include the integration of new design concepts to the delivery pipeline, for example. It also can involve other types of software testing beyond just automated integration tests.
Continuous Delivery (CD) is a core technique that stems from Continuous Integration (CI), where as per business needs, quality software is deployed frequently and predictably to Production in an automated fashion. This improves feedback and reduces shelf-time of new ideas, and thereby improves the sustainability of businesses. Continuous Delivery includes Continuous Deployment and Continuous Testing.
In most definitions, continuous delivery refers to the process of delivering software updates to users on a nearly constant basis. Continuous delivery is made possible by continuous integration and other optimizations at earlier stages of the development process. But the definition of continuous delivery gets a little cloudy when you start comparing it to continuous deployment.
The focus on Continuous Deployment is mostly relevant in domains where the end-user’s access to software updates relies on the update of some centralized source for this information and where this centralized source is not always easy to update because it’s monolithic or has (too) high coherence by nature (web, SOA, Databases etc.).
For a lot of domains that produces software where there is no centralized source of information (devices, consumer products, client installations etc.) or where the centralized source for information is easy to update (app stores artifact management systems, Open Source repositories etc.), there is almost no hype about the term Continuous Deployment at all. They just deploy; it’s not a big thing – it’s not a pain that requires special focus.
This distinction is a good way to think about the difference between the closely related concepts of continuous delivery and continuous deployment. It’s a distinction that will become increasingly important as technologies such as Docker make it easier to automate application deployment by allowing DevOps teams to drop new container images into production.