Software development and delivery practices continue to evolve and change, so on the heels of the late October DevOps Enterprise Summit, attendees and journalists alike have been asking, ‘Where does it all go from here?’
One area involves value streams, the creation of which allow organizations to see waste in their organization and eliminate for better efficiency and, ultimately, quality.
Another is CI/CD. The practice of continually introducing changes to the codebase and deploying those changes out for testing and feedback prior to wide release is well understood. So, how does the industry improve on continuous delivery?
Waving the flag for feature experimentation
Feature flags simplify feature development and testing
According to Adam Zimman, VP of platform at feature experimentation software provider LaunchDarkly, the future is through ‘progressive delivery.’
As defined by Redmonk analyst James Governor and Zimman in mid-2018, progressive delivery allows organizations to roll out changes while being mindful of the users’ experience. In a nutshell, Zimman said it’s about having increasing control over who gets to see what, when. “The idea of being able to garner feedback from specific cohorts prior to broad release of features or products has been a thing since people started selling stuff,” Zimman said. “In the past five years, as the ideas around more continuous delivery — a faster cadence of release cycles — has shifted what tools people look to to be able to do this type of experimentation or controlled rollout.”
A key tool to creating control points in software is a feature flag. Developers add these flags into their code that can be turned on or off for certain cohorts. It can be as simple as turning a feature on or off, or giving access in certain contexts but not in others. For instance, you might want to allow access to features in a staging environment for testing but not in production. And those types of access controls ultimately enable an organization to delegate who gets to manage them.
“If it’s something the developer is providing the feature flag mechanism themselves, or they’re storing the values in a simple database, then the ownership of that control resides with developers,” Zimman said. “You’re talking about accessing a database directly; you’re talking about changing value in that database, so you need to have some level of engineering background to be able to do that without shooting yourself in the foot, basically.”
Then, he added, as you start to roll that into production, “you may look to transition that ownership to an operations team, commensurate with a DevOps model where you want to have equal visibility and shared responsibility.” Finally, as you start to look at this functionality as it starts to impact users, you want to include the individual business owners that are closest to those business outcomes. “That could be product management, that could be product marketing, that could be sales, or customer success,” he continued. “All of these teams that are closer to business outcomes, we have seen in our customers being given responsibility for these control points.”
The use of feature flags has been associated with feature experimentation — A/B testing, blue-green deployments — but Zimman sees distinctions between experimentation and progressive delivery. “Often times, you think of an experiment, I want to put something out there and test if it’s better than what I had before. Or, if it’s something net new, then I want to see if people like it. But the goal of the experiment often times implies that you’re going to have an outcome that either is going to roll it back for everyone, so that no one gets that new thing because it was worse, or you’re going to roll it out to everyone.
“One of the key distinctions with progressive delivery,” he continued, “is the idea that you actually want to have an end state of this control point that is being thoughtful of the user base that it’s applicable to. I talk about this in the context of B2B. That makes a lot of sense for anybody who has kind of looked at the idea of mult-tiers of service, where you have a premium tier, and entry-level tier, and so on. You actually want new features to potentially to only go to one of those groups. You’re not actually rolling it out to everyone.”
In a post from Aug. 2018, Redmonk’s Governor wrote: “A great deal of our thinking in application delivery has been about consistency between development and deployment targets – see the promise of Docker and then Kubernetes. A core aspect of cattle vs pets as an analogy is that the cattle are all the same. The fleet is homogeneous. But we’re moving into a multicloud, multiplatform, hybrid world, where deployment targets are vary and we may want to route deployment and make it more, well, progressive.”
And that’s progress.