With the book he co-wrote with David Farley, Jez Humble can be considered one of the founders of the Continuous Delivery movement. In this article, he shares some of the experience he has gained since then.

Jez Humble’s first experience with continuous deployment was working in a startup in 2000:
“Me and the CTO would ftp files from our workstations directly into production; of course I don’t recommend that now,” he says with a smile.

Five years later, he was working at ThoughtWorks—an IT consultancy–on a team in a corporate “enterprise” environment. Here the team tried to get the custom software they were helping to build deployed to a production-like environment for testing purposes.
“It took us 2 weeks the first time and exposed a number of architectural problems,” Humble recalls. “In addition, it was a configuration management nightmare.”

Experience turned into a handbook
In the course of fixing that and a number of similar projects, Jez Humble and his co-worker Dave Farley distilled the ideas and experiences of colleagues involved in those projects into the Continuous Delivery book.

“We were very lucky inasmuch as several people in other parts of the world had come up with similar ideas,” says Humble. He mentions people like John Allspaw and Paul Hammond of Flickr and the wider community around the Velocity conference. The idea of agile infrastructure that evolved into DevOps was the brainchild of Patrick Debois and Andrew Shafer. John Willis contributed by writing a blog on this convergence. The term continuous deployment was coined by Timothy Fitz and Eric Ries at IMVU. “That along with the emergence of ‘the cloud’ meant that what began as a niche book on the dusty topic of build, test and deployment automation ended up where it is today,” Humble says.

According to Humble, Continuous Delivery is all about making it economic to work in small batches. From a general perspective, there are two goals of continuous delivery. The first is to speed up the process of creating and evolving software-based products. The second is to reduce the pain and risk of releases.
“As a side benefit, companies have also found that investing in practices such as continuous integration and comprehensive test and deployment automation has reduced costs and increased quality,” he says.

Two kinds of obstacles
According to Humble’s experience, the biggest obstacles for companies implementing Continuous Delivery tend to be architectural and organizational:

• In architectural terms, continuous delivery requires software that is easy to test and deploy in an automated way. Developers need to be able to run automated tests on their developer workstations and gain a high level of confidence the software is releasable rather than having to rely on complex, integrated environments to get this kind of feedback. “If we can find problems early on in the development process, they’re much cheaper to fix,” Humble says. ”In addition, developers can get fast feedback to “build quality in” rather than relying on testers to try and inspect for quality after ‘dev complete’”.
• The organizational problems are usually due to poor communication flow. This is either up and down the organization due to typical command-and-control management processes, or across the organization due to functional silos. “In order to move fast at scale, we rely on people working together across organizational boundaries,” Humble says. “We also rely on people at the edges of the organization having the authority and information necessary to make decisions locally that produce the correct results for the organization and its customers as a whole, and being able to get fast feedback if the outcome isn’t going to be the one they expected. These are preconditions for a culture of experimentation which can be found in all high performing organizations.”

Plenty of evolution remains
Regarding the future of Continuous Delivery, Humble thinks that it is seeing faster adoption now than a few years ago.
“To choose just one metric that is close to my heart, my CD book had higher sales in 2014 than any year previously,” Humble says. “Early adopters have been talking about these ideas for a few years now, but there’s an enormous number of companies who are only now beginning to seriously adopt agile practices, let alone CD. I think we will see plenty of evolution in the future – people are constantly coming up with new ideas, and we still have some way to go in our adoption of some relatively old ideas proposed by people like Taiichi Ohno, W Edwards Deming, Douglas McGregor, Peter Drucker, and Shigeo Shingo.”