Progressive delivery: Testing software through limited releases
Sometimes continuous delivery just isn’t enough for organizations that are constantly testing and adding features, especially those that want to roll out features to progressively larger audiences. The answer to this is progressive delivery.
The term progressive delivery was created in mid-2018 by Adam Zimman, the VP of Platform at LaunchDarkly, and James Governor, analyst and cofounder at RedMonk, to expand on continuous delivery’s notion of separating deployments and releases for organizations.
Organizations that adopted continuous delivery early on were primarily software-first organizations and their main delivery of value was through some sort of software package. Companies that didn’t have software as their only source of value faced challenges that weren’t really addressed by continuous delivery.
RELATED CONTENT:
Industry Watch: What follows CD? Progressive delivery
Learning about your software progressively
“When you start talking to the business, continuous deployment and continuous delivery tend to sound a little bit scary. If you talk to the business and say, look, we aren’t going to decouple these things. You decide when the business activation happens and you can do that because something is very well tested and you can test in production, you could be confident about when the services are rolled out and this will de-risk what you’re doing, then it sounds like they’re back in control,” Governor said.
All of the core testing concepts of progressive delivery existed in continuous delivery. Now, it’s a matter of what’s actually getting the focus since there are a lot more things organizations can do while utilizing the cloud.
Progressive delivery is a term that can be applied to a set of disciplines that people are already using now, whether that’s delivery and production excellence or organizations that are effectively testing and have a high level of confidence in their operations with a culture of troubleshooting and observability.
“If you look at Google, Amazon, and Microsoft from a public cloud perspective, they are all doing stuff like this even though they don’t always call it progressive delivery,” Governor said. “Once you start getting into banks and telcos, then it’s becoming a more generally applicable set of approaches and technologies.”
Progressive delivery really boils down to two core tenets: release progression and delegation, according to Zimman.
Release progression is all about adjusting the number of users that are able to see or interact with new features and new code at a pace that is appropriate for one’s business. It’s also about expanding it out only to the appropriate parties at any given time as part of the testing. That could mean only offering the feature to early access beta users first and then expanding it out to a trusted user group before expanding it out to everyone. Or maybe, the end state is to only give access to the people who are on the premium plan.
“The thing that [continuous delivery] stopped short of was it was more of a binary mentality,” Zimman said. “So it was either on or off for everyone, as opposed to this notion that we’re really focused on this ability for increasing your blast radius.”
Practicing release progression helps with the testing aspect of software delivery because the individual or team that built a new feature or a new widget can choose to deploy it and be the only ones that can interact with it.
“Everybody is testing in production. Some people do it on purpose, but if you’re not testing in production on purpose, chances are that you are going to be burned by a bad release or a lack of consistency between your test environment and your production environment.”
The other core aspect, release delegation, focuses on shifting release control from the engineering and operations organization out to the business owner.
“As soon as you move out of the realm of pure software organizations, in which their only value is through their software, you start recognizing that the business owners are actually looking for greater control and greater ability to impart change on digital experiences,” Zimman said.
Business owners can then customize what features they want to release to certain customers and even give the end users the ability to toggle certain features on and off, all while having guardrails put in place to make sure that the releases meet an industry’s compliance requirements.
A lot of companies are looking to do that autonomously and not have to go back to the engineering or operations team for the ability to control features, especially when it comes to things like beta testing, A/B testing or experimentation, according to Zimman.
Ravi Lachman, an evangelist at Harness, said that progressive delivery comes from getting feedback and this is especially important in the software development model of today where a lot of the time you’re doing the unknown and you don’t know what the impact is going to be. One of the quintessential firms that has relied on feedback for progressive delivery is Facebook.
“If you take it back 10 years ago, and you and I were downloading Facebook from the App Store, you and I would have two different download sizes and there’d be a reason for that. They’d be shipping different features for you and I,” Lachman said. “For example, I really like fried chicken and I’m on several fried chicken groups on Facebook.They might say, you know what, target him with cook-specific things and so how they started doing it was with the concept of progressive delivery. We’re not going to give all the users the same thing, and we want to be able to make sure that we can retract those features if they’re not performing well, or we can roll those features out if they are doing well and determine how we provide feedback and how we choose to deploy across our entire user base or our entire infrastructure.”
One common way that organizations are going about progressive delivery is by using feature flags. Feature flags give users fine-grained control over their deployments and remove the need to change config files, do blue-green deployments and perform rollbacks.
A new functionality would be wrapped up in a feature flag and then deployed to a new version of the application to a single production environment, allowing only users from the designated canary group to access the new functionality.
However, having too many feature flags at once can lead to sprawl and a difficulty in keeping track of what feature flags are out there. This prompted a demand for feature flag management solutions, which serve as a central spot for the management of the flags with a common API that tracks the whole feature flag life cycle — for example, what was the logic? How do you turn it on? How do you turn it off? Where did it go?
Progressive delivery is maturing
Progressive delivery is starting to become a more mature practice as vendors are coming and coalescing around it.
Governor said that this is the stage when it gets interesting because if you have a set of practices and then package them as a platform, it becomes something that a broader set of constituents can use.
In addition to new tooling, it’s also about shifting the delivery side of the equation mostly from the context of engineering readiness to business readiness.
“We don’t want to make any changes whatsoever to the deployment side of that equation because we want engineers to continue to develop at the pace of innovation, however fast they are comfortable with creating new technologies, features and code. They should continue to have that flexibility to do that creation and deployment into a production environment so that it is something where they’re able to test,” Zimman said.
Now, the release side of the equation is really the delivery of value, Zimman noted. In the context of engineering readiness, something is released when it’s ready. On the other hand, business readiness puts the business in charge of when and how to release new feature functionality or release when customers are actually ready to adopt this new feature functionality.
This might be great for a company running a deal-a-day site because their value is changing on a daily cadence, Zimman said.
Getting started with progressive delivery really requires getting all aspects of the business on board.
One has to talk to product management about experimentation with progressive delivery, talk to the business about delegating the service activation to the business and having delegated users, and then talk to software developers and say that this technology won’t slow them down and will just enable you to move more rapidly and with higher quality, Governor explained.
“The question that I like to ask enterprises is are you comfortable shipping code on a Friday afternoon?,” Governor said. “There are some people that will be like, no, the last thing I want to do is roll something out at 5PM on a Friday, because if something goes wrong, then there goes the weekend. Some organizations are like ‘well, yeah, that’s where we’re getting to, we do enough testing’ and really begin to say, yeah, we can ship a new service whenever. We have that confidence because we’ve done the engineering work and the cultural work in order to be able to do this. That’s progressive delivery.”
The post Progressive delivery: Testing software through limited releases appeared first on SD Times.
Tech Developers
No comments