Continuous Integration Versus Continuous Delivery Versus Continuous Deployment
Continuous integration, continuous delivery, and continuous deployment—if you do any work in the area of software delivery, it’s impossible not to encounter these terms on a regular basis. But what does each of these processes do for your product development and release cycles? I’ll explain what they really boil down to, what practices are associated with them, and what kinds of tooling are available to implement them in a manner that clearly depicts what they offer, how they differ, and how they work, both separately and together, to help release software to customers frequently, reliably, and with high quality.
Defining “Continuous”
Continuous here implies automation—automation in transforming source code into deliverables, in testing and validation, and even in installing and configuring software. It doesn’t imply that processes are continuously executing; rather, that when a new change is introduced into the system it can be automatically processed quickly and thus enables more frequent builds and faster testing, packaging, and releases than without continuous practices. Further, it enables quick identification and reporting of failures so that they can be fixed swiftly. This is commonly known as fail-fast.
Continuous here also implies that a change can proceed, without human intervention, through the stages of builds, testing, packaging, and so on. Combined, these stages form a “pipeline” of ...
Get Continuous Integration vs. Continuous Delivery vs. Continuous Deployment now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.