What Are the Benefits of a Continuous Delivery Platform?
The principal benefit of Continuous Delivery is that it creates a release process that is repeatable, reliable, and predictable, which in turn generates large reductions in cycle time, and hence gets features and bug fixes to users fast. The cost savings alone are worth the investment in time that the establishment and maintenance of such a release system entails.
Beyond that there are many other benefits, some of which are outlined below.
Empowering Teams
One of the key principles of the deployment pipeline is that it is a pull system—it allows testers, operations or support personnel to self-service the version of the application they want into the environment of their choice. In our experience, a major contributor to cycle time is people involved in the delivery process waiting to get a “good build” of the application. Often getting a good build requires endless emails being sent, tickets being raised, or other inefficient forms of communication. When the teams involved in delivery are distributed, this becomes a major source of inefficiency. With a deployment pipeline implementation, this problem is completely removed, everybody would have the ability to see which builds are available to be deployed into the environments they care about and be able to perform a deployment at the push of a button.
The ability to easily deploy any version of the software into any environment has many advantages.
- Testers can select older versions of an application to verify changes in behaviour in newer versions.
- Support staff can deploy a released version of the application into an environment to reproduce a defect.
- Operations staff can select a known good build to deploy to production as part of a disaster recovery exercise.
- Releases can be performed at the push of a button.
Overall, team members are more in control of their work, and so the quality of their work improves, which makes the quality of the solution improve. They collaborate more effectively, are less reactive, and can work more efficiently because they don’t spend so much time waiting for good builds to be pushed to them.
Reducing Errors
Errors can creep into software from all sorts of places. The people who commission the software in the first place can ask for the wrong thing. The analysts who capture the requirements can misunderstand, the developers can write buggy code. The errors we are talking about here, though, are specifically those introduced into production by poor configuration management. Think of the things that have to be just right to make a typical application work the right version of the code, sure, but also the correct version of the database schema, the correct configuration for load-balancers, the correct URL to that web service that you use to look up prices, and so forth. When we talk about configuration management, we mean the processes and mechanisms that allow you to identify and control that complete set of information, every last bit and byte.
Instead of waiting until the problem occurs, why not employ the machine assistance to prevent it happening in the first place?
By actively managing everything that can change in version control—such as configuration files, scripts to create databases and their schemas, build scripts, test harnesses, even development environments and operating system configurations—we allow computers to do what they are good at: ensure that every last bit and byte is in the place that we expect it to be.
In our experience, this dependence on manual configuration management is common. In many organisations that we have worked with, this is true of both their production systems and their test environments. Sometimes it may not matter that server A has its connection pool limited to 100 while server B has its pool set to 120. At other times it matters a lot.
When configuration parameters are manually defined and managed, they suffer from the human propensity for making mistakes in repetitive tasks. A simple typo in just the wrong place can stop an application in its tracks. Worse than that, programming languages have syntax checks and perhaps unit tests to verify that there are no typos. There are rarely checks of any kind applied to configuration information, particularly if that configuration information is typed directly into some console.
Once all of your configuration information is stored in a version control system, the next obvious step is to eliminate the middleman and get the computer to apply the configuration rather than to type it back in.
Lowering Stress
Of the obvious benefits, the most pleasant is the reduction in stress in all parties that are associated with a release. Most people who have ever come anywhere near a software project that is approaching its release date will be aware that these are indeed stressful events. We have seen sensible, conservative, quality-conscious project managers asking their developers, “Can’t you just modify the code?”.
For a moment, imagine that your upcoming release could be performed with the push of a button. Imagine that it could be performed within a few minutes, or even a few seconds, and that if the worst came to the worst, you could back out the release in the same few minutes or seconds. Imagine that you released frequently, so the delta between what is currently in production and the new release is small. If that were true, then the risk of release would be greatly diminished, and the unpleasant feeling that you are betting your career on its success significantly reduced.
The key to reducing stress is to have the kind of automated deployment process that we have described, to perform it frequently, and to have a good story when it comes to your ability to back changes out should the worst happen.
Deployment Flexibility
It should be a simple task to start your application in a new environment—ideally just a matter of commissioning the machines or virtual images and creating some configuration information that describes the environment’s unique properties. Then you should be able to use your automated deployment process to prepare the new environment for deployment and deploy the chosen version of your application to it.
Practice Makes Perfect
Any team that uses continuous integration or iterative, incremental development techniques will need to deploy the application frequently.
The best strategy to adopt is to use the same deployment approach whatever the deployment target. There should not be a special QA deployment strategy, or a special acceptance test, or production deployment strategy. In this way every time the application is deployed, we are confirming that our deployment mechanism is working correctly. In essence, the final deployment into production is being rehearsed every single time the software is deployed to any target.