The “continuous delivery” process of building, testing and deploying software is relatively unknown — but that could be about to change thanks to the publication of a new book on the subject.
“Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation,” (Addison-Wesley Signature Series (Fowler), is written by Jez Humble and David Farley, and is available from major booksellers
The basic idea behind continuous delivery is that by automating the build, deployment, and testing process, and creating improved collaboration between developers, testers, and operations, delivery teams can release software updates in a matter of hours–sometimes even in minutes, regardless of the size of a project or the complexity of its code.
[login]
“Think of continuous delivery as Agile on steroids,” said David Thomas, a software engineer at Rally, a leader in Agile application lifecycle management. “It is an extreme form of agile and lean software development that seeks to minimize waste and maximize speed and efficiency.”
Clearly, continuous delivery is not for everybody.
“But, if you’re in an environment where you need or want to deploy changes to production 50 times per day, continuous delivery will enable you to do so,” said Thomas.
This is still very cutting-edge stuff, he added, noting that the concept of continuous delivery only began surfacing in conferences and forums about a year or two ago.
“Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation” covers build and deployment automation, continuous integration, test automation, managing infrastructure and environments, configuration management, version control practices, data migration automation, and even governance, wrote Humble in a recent blog.
The book has two primary themes: automation and collaboration.
Delivering software of any complexity involves people with a bunch of skills: testers, developers, and sysadmin / operations personnel,” said Jez Humble.
The last group of people often gets left out of the process of delivering software until the end, and even testers are often not as heavily involved in the development process as they should be.
“It’s a pattern we see over and over again when helping people deliver software, and it inevitably leads to unacceptable numbers of defects, poor architectural decisions, and lengthy and unpredictable delays to getting releases out of the door,” said Humble.
One of the main aims of the book is to provide a framework so everybody involved in the delivery process can work together from the beginning.
Automation is key to enabling such collaboration.
When most of the process of software creation, testing and deployment is manual, the process can be very error-prone. Using manual practices, delivery teams typically spend a large proportion of their time scrambling to merge branches and create new builds created so they can be deployed into a production-like environment and tested.
This inevitably means that the feedback loop from testing is incredibly slow, and doing things such as load testing on staging environments gets left till late in the process, rather than being done from the beginning when problems can be fixed cheaply.
Automating as much as possible of the delivery process ensures a much tighter feedback loop, said Humble. “It also frees people to focus on high-value activities such as evolving an appropriate architecture, exploratory testing, and making deployments and releases low-risk, push-button processes.”
The Deployment Pipeline
There is also an organizing principle for all of these activities: the deployment pipeline.
The description and elaboration of this pipeline forms the core of the book. The idea behind the pipeline is to help developers model each part of the value stream that goes from check-in to release, and then to automate it. Every check-in triggers a new build, which then passes through the deployment pipeline as shown below.
The authors of the book claim the deployment pipeline allows everybody involved in delivering software to get fast feedback on the status of every change introduced to an application. The theory is that such feedback makes it simple to trace which builds have been through which environments, what the results were, and what’s currently in each environment.
Finally, it allows testers and operations people to self-service the build of their choice into the environment they control. The upshot is faster feedback, better collaboration within delivery teams, and — because each process from check-in to release is automated – fewer errors, more reliable releases, and shorter cycle times.
