Progressive delivery is the natural extension of continuous delivery but refines what it means to “deliver” because unlike the ‘big bang’ of an all-or-nothing release cutover, progressive delivery enables the business to gradually expose new functionality to limited numbers of users to assess the impact on user behavior and system health before expanding the release to the entire user base.

RedMonk founder James Governor, who coined the term progressive delivery in 2018 to describe a basket of related skills and technologies for gradual releases that reduce risk in application delivery, announced his 2020 research topics recently and at the top of his list was progressive delivery. 

It’s great to experiment to ensure your software works as intended, yet progressive delivery is motivated by business factors — if the company releases software and business metrics go down, it’s better to know that before a wider release. “I want to watch it to limit the blast radius, so as I’m ramping it up, I want to be able to know whether it’s going well or not,” explained Dave Karow, Continuous Delivery evangelist at feature delivery platform provider Split Software. “I want to learn before I get to 100%. You know, one of our senior engineering leaders used to be at a very large file-sharing provider and he admitted that even when they used gradual rollouts, they didn’t tend to learn about [issues] until they were past the 50% mark. That’s painful compared to finding problems earlier in a gradual rollout. You want to set yourself up to learn about unforeseen issues as quickly as possible in production, and it would be nice if you didn’t have to hurt most of your users — if not all of them — before you figured out you had an incident.”

These patterns have been used by the largest e-commerce leaders for years. At Walmart, they use Progressive Delivery for two main purposes: one is called “test to learn,” and the other is “test to launch.” Test to learn is essentially A/B testing; which version of the software yields more of the desired user behaviors, such as buying more items or signing up for premium services. Test to launch, on the other hand, is more like application monitoring, where you’re watching a gradual rollout of the application to see that not only systems metrics, but also business metrics, don’t decline as the software is given to more users.

The ability to effectively roll out software to small cohorts before wide release to assess impact on the business comes with the assumption that business and development people are on the same page. Karow said he’s seeing the greatest success with progressive delivery in Agile and DevOps teams.

“Those who most embrace this and get the most value out of it are already sort of in a two-pizza team,” Karow said, referring to Amazon CEO Jeff Bezos’ belief that if a team is so large that you can’t feed it with two pizzas, if won’t work effectively. “I have everybody related to this project within shouting distance of each other in a room or at least that tight in terms of a remote teaming thing, so that there’s no specification being written by one group and coding being done by another group and testing being done by another group and deployment being done by another group. Everybody knows what we’re building this week, and what we are trying to accomplish.”

These teams, he added, understand they might not get it exactly right the first time, so they’re looking to see how they can iterate quickly to improve it. “We don’t want to mark it ‘done’ because we shipped; we want to mark it ‘done’ because we moved the number.”

Split’s feature delivery management software is the means by which people work together to experiment with and deliver quality software that meets business and user requirements. “If [companies] are still solving fundamental problems to get people talking to each other and get the business and the developers on the same page, we’re not a silver bullet for that. We’re the means by which to actually do work together, not to get people to work together.”

With progressive delivery, there is a natural progression of cohorts you want to expose to new code in production, Karow said. “The first cohort you want to expose in production to the new code is your developers and your testers. This gives them one last chance to be sure everything works as expected in the actual production environment, without any risk to users. Then there’s dogfooding. If I use my own product, then I’m going to go from my developers and testers to my non-developer users. Then I might go out to my friendlies, or my freebies.  Finally, I’ll begin rolling it out to the rest of my general population.”

Learn more at: www.split.io

 

Content provided by SD Times and Split Software