Continuous Delivery is the process by which features deployed into production are released incrementally or immediately to customers based on market demand. Nearly all Agile teams favor an incremental delivery strategy. In an Agile context, this means that each successive version of the product is usable, and each builds upon the previous version by adding user-visible functionality.
Continuous delivery is sometimes confused with continuous deployment. Continuous deployment means that every change is automatically deployed to production, whereas continuous delivery means that the team ensures every change can be deployed to production but may choose not to do it, usually due to business reasons.
To go deeper into this, continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready.
Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements, and in order to do continuous deployment, one must be doing continuous delivery.
While continuous deployment may not be right for every company, continuous delivery is an absolute requirement of Agile and DevOps practices. Only when you continuously deliver your code can you have true confidence that your changes will be serving value to your customers within minutes of pushing the “go” button, and that you can actually push that button any time the business is ready for it.
Enabling large teams to support continuous, incremental delivery requires more coordination than Agile 1.0. If teams aren’t careful, it can become a very manual and error-prone process to understand what has already been delivered and to define the next releases that will incrementally improve the product.
To support continuous incremental delivery, your organization needs to:
This allows you to reference the organizational knowledge of corporate standards, architecture, and compliance requirements that were defined for previous releases.
The Agile manifesto prioritizes working software over documentation, but Agile teams often include new people who were not involved in the initial release, stakeholders who do not have complete access to the software, or are large and distributed. This means that despite focusing on delivering working software over documentation, you still need to ensure you have sufficient documentation to properly enable your teams by providing a better context of the complete solution.
Effective Agile 2.0 practices incorporate feedback from the market – not just in the form of defects, but also considering market adoption, user feedback, and corporate business initiatives. To take all these into account, you need lightweight, visual models that enable your teams to quickly understand the design and definition of the new solutions required and quickly deliver on this market feedback.
To be successful at continuous delivery or continuous deployment, it is critical to do continuous integration and continuous testing well. With a solid foundation, you will win on all three fronts: quality, frequently, and predictability.
A continuous delivery pipeline helps your ideas become products through a series of sustainable experiments. If you discover your idea isn’t as good as you thought it was, you can quickly turn around with a better idea. Additionally, pipelines reduce the mean time to resolve production issues, thus reducing downtime for your customers. With continuous delivery, you end up with more productive teams and satisfied customers, and who doesn’t want that?