Deployments not Releases
“Dave, we can’t release more often, our customers wouldn’t tolerate it.” Having been an architect in Infrastructure Engineering at Salesforce, I’m very familiar with customers being intolerant of continual changes to UI or features. However, there is simply more to shipping than UI tweaks and features.
In his book, Project to Product , Dr. Mik Kersten describes four different “flow items” that can move through the system and that should be adjusted to different proportions based on the changing needs of the business. They are:
- Features - new functionality, changing that button from orange to purple
- Defects - bugs. Broken functionality that gives the user a bad/wrong experience.
- Risks - security and compliance problems. Things that will cost your business money if they are not fixed.
- Debt - Things that are a burden on the business objectives. Things that slow down the speed or quality of delivery.
A horribly incomplete list of things that can be released that are not Features: Rails upgrades, updated Amazon Machine Images (AMIs)/container images, algorithmic optimization, user behavior collection, blog posts, observability improvements, database upgrades, redeploying infrastructure with IaC, dogfood features, replacing credentials with a proper secrets store…
Of course, we still want to release features, but in order to release often we need to…
Make it Safe
Some of these things can be released by developers, some by operations, and some by marketing! But how can it be safe for marketing to release?
Feature flags. Feature flags allow those teams to deploy software more safely. Being able to deploy more safely means we deploy more often, which means we get better at deploying (because: practice, practice, practice).
When deployments go out behind a robust feature flagging mechanism (slice by group, by percentage, by customerid, etc) , companies don’t need to worry about “releases” anymore. When you do this, releases are no longer an engineering term, but rather a marketing term. They describe a collection of deployments that are considered a “release” even though each of those deployments was pushed to production at a different time. They may be activated individually or as a group, but they are no longer collected into a big batch release. We want to do this because the science is clear that small batch deployment is safer and better for rapidly achieving desired business outcomes.
Sometimes portfolio companies do feature flagging in customer database records, sometimes they push all changes to a staging environment and then release them at once. Make the leap. Move to robust feature flagging, deploy to production behind a flag that can be instantly turned on or off.
With this in place, Marketing can make noise in the marketplace with features they know have been tested and work well. The business can retain talent with more modern software, retain customers with infrastructure that is continually kept secure and performant, and win in the marketplace without feature releases.