Engineering Improvement Runbook | Engineering Practices

April 6th, 2021

Progressive Delivery: Is it the future of software delivery?

Progressive delivery is a way where you ship the feature but ship it disabled, and then you have some way to progressively turn it on whenever you want or turn it off whenever you want. This is a key technique in order to move from shipping code once every week or once every month, where deployments usually take a long time, they're very risky because they have a lot of changes in them. They could go bad and that's very costly and so you try to put a lot of QA processes behind it to make sure that the code is good. It's just a very heavyweight thing and that's traditionally how we've done things.

Progressive delivery goes the other direction where it tries to make it so you can ship code quickly and fast without having to wait for your code to go through a heavy QA process because it's shipped turned off and you use features like feature flags to turn on that feature whenever you want. A very common way to do it is you turn it on for your QA department, so your QA department gets to see the new book buying interface and they can use that. However, your customers don't get to see that new feature. Once the QA department's happy with it, then you can turn it on.

Another reason you might want to do this is you might want to... Let's say you're setting up a new database cache and you're pretty sure it's going to scale, but you're not a hundred percent sure. What you do is you set up that cache, ship it disabled. Then you turn it on for 1% of customers, see if there's a problem and, if so, turn it off, or you can smartly segment your customers. For example, let's say that anyone who's on a trial license for your software, you'll ship it out to them first because you want them to have the greatest and latest and if it breaks, they're not paying you any money anyways. Or maybe your free customer, you use those as your guinea pigs. You ship turn on the feature for the free customers and if the feature works as expected, you turn it on for more and more, and maybe your last feature is your big enterprise customers that are giving you hundreds of thousands of dollars.

So you're able to disconnect shipping code with enabling a feature. That's what it means by progressive delivery. You're not delivering it when you ship. You're delivering it incrementally whenever it makes sense for you and your business.

Like a canary release.

Yeah, it's similar to a canary release but it's even deeper than a canary release. So canary release is where you take a version of your software and you throw it up on one server and you see how that works, and if that works great then you throw it up on other servers. So it's kind of like that except for at a lower feature level and it's much more fine grained, because a canary release is something that's going to be built into your deployment pipeline and once you figure out it's a server and something else, that's just the way it is.

You can't say, "Well, I'm going to turn it on for Bob but not Sarah, but maybe this person." You can do that sort of thing with a feature flag. You can't really do that very easily with a canary release, in a traditional Canary release style. There are ways that you can hybridize between the two systems.

Is that good for A/B testing or something, too? Yes, you can A/B test. I guess what I would do is I would caution you because A/B testing, that's where you show one version of a feature and then show another version of the same feature, perhaps, and then you see the engagement rate with both of those, and whichever one's higher, that's the one you ship in the end. They're also known as experiments. For example, Facebook is notorious for turning on some new thing that they're experimenting with for a very small portion of their customer base and then if that goes well, then they'll roll it out, and if it doesn't then you'll never hear about it again.

Thing with that is that A/B testing process is not really an engineering activity, but that's more of a product management activity. Meaning an engineering activity is something like I want to see if this thing scales or this is going to be stable, so it has to do with the software and how it operates. Whereas A/B testing is primarily is this the right product feature or not? And so the person flipping that switch is usually going to be a product manager who is going to want to have a lot of analytics around those two features so that they can compare that to make their decision on what the product should do. Whereas the customer for a feature flag, like a scale or stability one, is going to be an engineer deciding on how to roll out this feature.

So they're very similar but their audiences are different. In both cases, you're going to need metrics to see which one it worked and which one it didn't. In both cases, you're going to want to be very selective and progressive. So yeah, I would say that way, they're very similar. Just be careful. They're very different audiences, and the systems that track analytics are most often very different than the systems that track application health. One's going to be in Datadog or CloudWatch. The other one is going to be in things like an Amplitude or some sort of analytic system.

Feature flag toggles

Feature flag toggles are super powerful. I use them a lot in your job. Absolutely. Yep, I hear you. That's probably one of the biggest things I think that has come out of software engineering in the last five to 10 years is how powerful feature flags are. One of my friends is the CTO and co-founder, John Kodumal of LaunchDarkly, which is probably one of the biggest feature flag companies, and man, I remember when I first heard it, I was like, "Come on, you can't really create a product around feature flags. That's a little thing that I wrote in a couple of days. How could you create a whole company around it?"

And then eventually I saw the light and Atlassian became one of their first big company customers, because I was working for the Atlassian at the time, and now they're worth a billion plus dollars because, yes, it turns out that is a great idea and there are so many more things that it does than just the simple button where you turn on or off.