Continuous Delivery vs. Delivering Continuously
CEO of http://huettermann.net
Continuous delivery is a new mindset for development and delivery of software to add value to the system and satisfy the customer. It is also possible to “deliver continuously” (for some people, delivering once a year is “continuously,” too) just by throwing changes to production randomly, with bad quality. Thus, a systematic process of staging of software is crucial, along with introducing collaboration between development and operations to reduce cycle time and fulfill holistic business goals, often called key performance indicators. Without DevOps, there’s no continuous delivery.
Whereas DevOps deals with collaboration between development and operations, continuous delivery focuses on the concept of bringing changes to production continuously and with minimized cycle time—and being able to do so frequently. Particularly crucial elements for implementing DevOps are:
- Aligning development and operations with the same goals, which are in turn aligned with overall business goals;
- Fostering a mind shift and introducing slack time and room for experimenting; a bit of firefighting is okay—you learn a lot through firefighting—but time for innovation is even better;
- Aligning processes and tools and finding the optimal tradeoff for configuration management;
- Finding the right balance of manual work and automated processes (be aware of the irony as well as the paradox of automation);
- Aligning the changes in the delivery pipeline with the business, not the technique;
- Realizing that the delivery pipeline is not a one-direction fire-and-forget tube but rather an integrated life cycle;
- Fostering the mindset that a single change may result in a potential release and may start the whole process; and
- Finding semantic containers for your release, including all artifact types, that are versioned and executable.
Continuous delivery spans the software life cycle and is based on continuous integration (that is, checking changes into version control multiple times a day, with the constraint that developers can check out current states of the software at any time without having any build errors locally afterwards), continuous deployment (that is, the frequent deployment of changes to target environments), and continuous inspection (that is, the inspect-and-adapt pattern to keep up the internal and external quality of the software).
Continuous delivery is not necessarily part of a DevOps initiative. In other words, if you implement continuous delivery, you’ll most likely have to implement some sort of DevOps, too. I wish you much fun and success with your continuous delivery initiative—and don’t forget to shape your DevOps approach.