As we generally don’t focus on making up terms for tech trends and technologies at RedMonk it’s been interesting to see one that we did come up with take flight – Progressive Delivery, one of my key themes for 2020. When you start reading posts and news articles by people that you haven’t spoken to, about an idea you came up with, it’s pretty neat.
So Progressive Delivery. I think David Eastman has a really nice approach to story telling, to draw the reader in, in this piece From Automated Cloud Deployment to Progressive Delivery.
Let’s go back to the early idea of a release. It was a collection of all the features and fixes the loudest stakeholders had persuaded the product owner to put at the top of the story list. A date was promised, but QA was late, and the persistent stakeholders squeezed a little more juice out of a story. Then it was stuffed into a ball and delivered to your servers overnight, lest anyone notice. The next day, the developers had to deal with the fallout as the support queues grew with confused users.
While developers were getting the hang of the agile notion of automated deployment, the release lifecycle did pretty much end with a deployment going live. This gave certainty that what had been built and placed in the artifact repository was the same thing the testers had seen in the staging environment. And it also had the changes Jira said it had.
This type of release was very much like a birthday present. Your uncle talked to your dad briefly, without your knowledge, and agreed you really would benefit from a new pair of socks. Then these were delivered on the day with the receipt in the bag, just in case you needed to take them back.
The first evolution came with the concept that a release wasn’t exactly synonymous with a deployment. Finally, the end-user’s perspective nudged its way into corporate release strategy–updates could be deployed without necessarily impinging directly on every user. What if there were two identical release environments with clever network switching, meaning only one was truly live? This type of flip-flop arrangement (sometimes referred to as blue/green deployment) allowed changes to be tested internally in a realistic environment before going live.
It was the advertising industry that prompted the idea of A/B testing.
It’s definitely worth reading the whole post.
Another piece I enjoyed is The Road to Progressive Delivery by Shilpi at Opensense Labs. It’s a surprisingly comprehensive weaving together of threads, and what I really enjoyed was the focus on business user concerns and the clarity, for example on benefits for “IT professionals.”
IT professionals who choose the path of progressive delivery avail the following major benefits.
– The capability to quality control the features as they are distributed.
– The ability to plan for the failures or issues as only a small number of users are affected if the features don’t work correctly.
– It facilitates the feedback collection from a group of expert users to revamp the changes before distributing them out to the client.
– Progressive delivery allows development teams to add more value to the development process and less time in managing the risks.
– The non-engineering teams, such as marketing or sales, can release the features to the users based on separate business timelines.
I am flattered by the amount of validation from folks like Dave Karow, Continuous Delivery evangelist at Split Software – a feature flag management vendor. Dave is all about fast feedback loops in feature delivery, enabling effective experimentation. Dave has done a whole series of videos and posts about Progressive Delivery.
The Path to Progressive Delivery
Progressive Delivery isn’t really a new thing, as much as it is a new term to describe something that’s been emerging for quite some time.
Four Shades of Progressive Delivery
We have individual features that we can toggle or ramp up and down. That’s really important, because it’s pretty rare that you’re only taking one thing live in a deployment.
Let’s say you take five code changes (i.e. features) live in your deployment.
Along the way, you notice that just one of them has a problem. With a Blue/Green or a Canary, the other four features have to roll back as well. The features that are OK are forced to go away and wait for another delivery vehicle.
With feature flags, you can continue to roll out the four good features even as you roll back the fifth one to fix it.
Dave is presenting next week at DeliveryConf in Seattle next week, an independent community-led conference which looks *excellent*. The title of his talk Progressive Delivery Patterns In The Wild draws me straight in. That is, as they say, relevant to my interests. Dave plans to include lessons from booking.com, LinkedIn and Facebook. Sounds excellent.
Finally, in recent extremely pleasing news came this incredible quote by Charity Majors.
The term "Progressive Delivery" tops my own list of tech breakthroughs in 2019, after talking about it namelessly and vexatiously for half a decade.
So I am almost as delighted to see observability on @monkchips's areas of research for 2020. :evilburns: https://t.co/HhnZYGW3VW
— Charity Majors (@mipsytipsy) January 13, 2020
So that’s a few links to consider, and there will be more. I definitely don’t own Progressive Delivery, I just gave it a name.
No Comments