The focus of continuous delivery isn’t just about being quicker when developing and deploying, but rather delivering business value continuously. And we only see business value from software when it is made available to end users.
I heard a project lead explain that his team had a continuous delivery process. They used source control management and had a continuous integration engine that compiled the code and ran unit tests and static analysis. They packaged and deployed the build to a fresh and automatically provisioned series of virtual machines where functional tests were run.
As they reached the end of their schedule, they sent the packages to the client, and over the course of a few weeks the client worked with them to get those systems stood up and the other dependencies configured. Hard drives with virtual machines were mailed, issues found and fixed, and new packages sent over until the system was ready for the client and users to evaluate.
To me, this sounds like continuous integration (CI), not continuous delivery. Certainly advanced CI, but still just CI. All the technical steps for a continuous delivery process are there, but it still isn’t continuous delivery.
One problem is the lag and effort between sending the software to the client and the client being able to use it. But even if the installation process was improved and the time cut down to hours rather than weeks, it still wouldn’t be continuous delivery.
Why? Because the decision to release was made by the development team. They worked to get the software ready to deliver on a certain date, and on that date they started to get the software installed and ready for the users in the client’s environment. The business may have set the date at the beginning of the project, but had no say after that.
Continuous delivery means deployment is a business decision. When the business owner says “I want the latest features,” a team with a continuous delivery process can get it to them and it is available to the end users soon after — whether that is minutes, hours, or even a day or two later.
Also, If the client decides a week later that they want the new features again, that can still happen right away. If the team has to drop everything else it is doing to get the release out, it can’t be continuous.
That decision to deploy can be automatic — if all the tests and controls are green, the software automatically goes live every time. Sites like Flickr have continuous delivery taken to an extreme as continuous deployment; they deploy to production multiple times a day. Flickr has made the business decision that they always want the latest software as soon as they can have it.
The other end of the spectrum can be just a decision point at the end of a sprint or iteration on whether the latest code should be deployed or shipped. Push-button deployment is a valuable capability to have, but the real key is the time and effort between the business decision and delivery of business value.
