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 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access