An idea known as continuous delivery is gaining traction among software professionals. The practice -- developing...
and testing software so that organizations can quickly issue updates anytime -- has taken hold among software giants such as Amazon, which reportedly releases software every 11.6 seconds.
But continuous delivery is not just for the likes of Amazon, Facebook, Google and Twitter, which manage massive, constantly changing codebases. The practice has benefits and implications for all software organizations, especially those with mature Agile teams in place.
Continuous delivery moves an organization beyond the "big-release" approach to going live with new software. The longstanding process too often involves last-minute testing, uncertainty about code quality and pressure from the product owner to meet the release deadline. "The idea of one big go-live day is ridiculous," said Software Development Expert Mary Poppendieck. "Google, Amazon [and] Twitter figured this out long ago," she said, referring to early adopters of continuous delivery.
Continuous delivery builds on Agile
Continuous delivery can open new doors for marketing and product management professionals. But for software pros, it is a natural outgrowth of Agile development, said Johanna Rothman, a software development expert who heads Rothman Consulting Group Inc. "It's just another step in Agile that builds on continuous integration (CI). You cannot do continuous delivery if you're not doing continuous integration," she said.
In CI, small, incremental changes to software are continually tested and committed to the codebase, in order to find and fix defects fast. Continuous delivery takes that a step further, releasing well-tested software in small increments.
Not surprisingly, continuous delivery requires software organizations to move beyond manual test and release processes. "It is achieved through automation of the build, deploy, test and release process," Jez Humble wrote in a February 2014 blog post, "The Case for Continuous Delivery." A former principal at software consultancy ThoughtWorks, Humble is a co-author of the forthcoming book, Lean Enterprise: Adopting Continuous Delivery, DevOps, and Lean Startup at Scale. He is widely credited with popularizing the practice of continuous delivery.
Continuous delivery is all about doing things in small steps. For instance, to make sure that work flows steadily through the development process, you need small stories. "Large stories–anything that impedes flow—are at odds with continuous delivery," Rothman said. "In continuous delivery, you have many teams finishing small stories all the time. As soon they finish something, they update the software whenever they want."
The big benefit of small updates: A stable codebase
Keeping things small has another big benefit. "Small releases keep complex codebases stable," said Poppendieck. "The idea of one big go-live day is ridiculous. Google, Amazon, Twitter figured this out long ago," she said, referring to early adopters of continuous delivery.
All large software projects, and embedded software projects, are by nature complex, she said. The only way to achieve stability in this complex environment is to "perturb the system in a small way, and observe the result." That is what's happening in continuous delivery, Poppendieck said.
For most software organizations, small continual changes represent a new way of thinking. It's a radical departure from traditional "big 1.0, 2.0, 3.0 releases" followed by point releases, noted Stephen Forte, chief strategy officer at mobile tool maker Telerik. "The process of being able to rapidly deploy new features incrementally is an amazing thing." One notion that has emerged from continuous delivery is the idea that "software is evolving every day," he said.
Constant releases -- not necessarily to customers
Continuous delivery doesn't mean that every software update should be delivered to the customer, Rothman said. In other words, just because you have the technical capability to deliver software updates to customers constantly doesn't mean you should. "When you release software to the customer is a business decision. You might decide to do that four times a year--depending on what type of business you're in." But behind the scenes, the practice of continuous delivery takes place. Instead of directing software updates to customers, updates are deployed to a staging server. "We have tested [the code]. We know it works. But we don't turn it on," Rothman said. The idea that once a feature is tested it gets packaged into a product release is a "legacy from Waterfall thinking," which is all about "stages and gates" she said.
Continuous testing = higher quality code
Continually deploying software updates to a staging server boosts the quality of code over time. As feature after feature gets integrated into the codebase, and tested and re-tested each time, the overall code quality keeps rising. Poppendieck describes this approach as a "very aggressive structure of testing." By releasing in small increments—and running increasingly sophisticated tests "we know that every single one of these [increments] is safe and works with the larger codebase," she said.
In an article published in SoftwareQuality.com, development expert Nari Kannan explained the process of boosting quality like this: "When you do multiple build-test-deployment cycles a day, the test automation exercises the entire software many times a day, catching any software defect that slips through anytime."
Business benefit: Testing marketing messages
Reducing software defects is good for business. But that's not why business people care about continuous delivery. It turns out that the ability to quickly release and pull back software has profound implications for marketing and other business professionals, said Telerik's Forte. Continuous delivery allows them to roll out two different marketing messages, for example, and get fast feedback on which one resulted in a higher conversion rate, he said. "Which marketing message resonated better? It's classic A/B testing," said Forte. "You cannot do that without continuous delivery."
Another business benefit of continuous delivery is the ability to respond rapidly when unforeseen events occur. Recent security breaches are a good example, Forte said. You can find the bug—the flaw in the code that let hackers steal credit card numbers—and fix it fast. "In the past, that would have [required] a Herculean effort," he said.
Continuous delivery: A godsend to product managers
Continuous delivery also has significant implications for the way a business develops new products, Poppendieck said. "It enables the rapid flow of product ideas into production. That means you can experiment. You can test a feature and pull it back," she said. "Continuous delivery is a Godsend to product managers."
Knowing early what works and what doesn't can prevent disasters, she said, referring to the failed launch of healthcare.gov. If they had tested features during product development, they would have found out early that users of the application "didn't want to fill out a million forms" before being presented with information on policies and prices, Poppendieck said. "Continuous delivery lets you implement quickly and get feedback in a short time. And that is a product manager's objective."
Making a commitment to continuous delivery
The business and the technology benefits of continuous delivery are considerable. But neither can be fully realized without support from top management. Software pros can't do continuous delivery without investing in test automation and DevOps And the practice will also require some organizations to make a deeper commitment to Agile ways of working than they have in the past. Once you have the technology infrastructure in place, how do you get top management on board? "You can't influence the business overnight," said Forte. But you can provide business executives with insight they didn't have access to before, he said. "Did you know we deployed [this new feature] and it increased traffic by X?" That will get the boss's attention, he said. "They will come back and say 'can we do this; can we do that?' They won't use the term "continuous delivery," but that's what they are really asking for, Forte said.
Has continuous delivery become a must for developers?
Continuous delivery and Agile pave the road for one company's success