If you aren't practicing iterative development, you aren't ready for continuous delivery.
If you aren't doing automated testing, you aren't ready for continuous delivery.
If you don't have a quick way to see what happens to code when it's deployed on your infrastructure, you aren't ready for continuous delivery.
If you don't have a staging environment for review before production release, you aren't ready for continuous delivery.
If the business you work for hasn't made a commitment to continuous delivery, you cannot reap the full benefit of ongoing, rapid software releases.
"Continuous delivery is the sum of a series of practices," said Carl Caum, prototype engineer at Puppet Labs. "The end goal is to deploy every [software] change at the push of a button. But there are numerous problems you have to solve before you can do that."
In this two-part series, Caum and other continuous delivery experts outline those problems -- which define the prerequisites for charting a course to continuous delivery. This article, the first in the series, discusses what continuous delivery is, and explains how an established, iterative development practice sets the foundation for this new way of releasing software.
The second article in the series examines why automated testing, adopting infrastructure-as-code practices and establishing a staging environment are essential aspects of this new approach to delivering software.
Neither tip in this two-part series focuses primarily on the business benefits of continuous delivery. But it bears repeating that software organizations cannot succeed at continuous delivery unless they make a sustained commitment to this process. "Fundamentally, continuous delivery is a business decision, and if management doesn't get it, it's a tough sell." said Mary Poppendieck, co-author with Tom Poppendieck of The Lean Mindset, among other books.
The foundation: Iterative development
Continuous delivery is not a software development methodology per se. It is a practice -- or rather, a series of practices -- of developing and testing software in a way that lets organizations quickly issue updates anytime.
Many software developers and testers see it as a natural outgrowth of Agile development. They are not wrong, but a broader definition is more accurate. What really prepares a software team to take on continuous delivery is solid experience with any form of iterative development. "There is a tendency to pigeonhole methodologies," said Eric Nguyen, director of business intelligence at Jama Software, a company that sells requirements and test management software. But how a software team defines itself -- Scrum, Agile, KanBan -- doesn't matter, said Stephen Forte, chief strategy officer at tool maker Telerik. "They are all adapting toward continuous delivery."
What does matter is a mind-set that says, "Be more iterative," Nguyen said. Whether you're scripting tests, writing and testing code, or defining a business problem, "you are breaking things down into smaller and smaller [pieces]," he added. And that is ultimately what continuous delivery is all about.
Building on earlier practices
Continuous delivery requires software teams to build on earlier, familiar iterative practices, such as continuous integration, Puppet Labs' Caum said. "Continuous integration provides a quick feedback loop for developers, letting them know whether the code works." Continuous delivery takes it a step further. "It lets you deploy that code and see how it works," he said.
In short, iterative development is the foundation on which continuous delivery rests. If you aren't practicing iterative development, you are not ready to take on continuous delivery.
Why Continuous code delivery may be critical, but not always secure
Who really knows best when it comes to UI design