It’s known that modern companies, especially the ones that have adopted agile principles, have achieved a faster degree of delivery cadence, deploy many times per day, diminished the risk of each release, and lowered the time to fix defects in production environments.
Feature flags are one of the few key technologies that enables this transformation because it allows you to decouple pushes from releases, but do they really deliver the benefit of “killing the release” night? Do they make it so that software delivery is more of a day-to-day thing when more people are around to help and not the stuff of late night heroics?
Most people are using feature flags to release software during business hours.
I decided to look at the data we gathered a sample from our customers who run more than 300 billion feature flags per month to see what I could find.
For the analysis we show several actions done to a feature flag in production environments, such as creation, updates, rollbacks -aka kills- among others, for the last six months. All timestamps have been normalized to the timezone of the user making the change.
Below you can see that the majority of the feature flag changes take place within the usual work hours of 8 am to 6 pm. Notice the dip in activity mid-day. I joked to my coworkers that feature flags changes also take a lunch break!
In the first graph, we have feature flag changes by hour of the day. You can see Updates (red) include changes to rollout plan and targeting, Create (orange), Kills (green), and Resets (light green).
In the second graph, we focus just on kills to see the clear trend throughout the work day.
Feature flags changes also take a lunch break!
This third graph displays the feature flag change distribution by the day of the week in which they were made. It shows that, indeed, the majority of the changes take place during work weeks and not on weekends.
Some articles out there talk about the absolute worst time for a deploy (in this context deploy==release). They often mention Monday morning (not enough time to prepare properly), at the end of a work day (as no one will be around to help) and Friday afternoon (similarly, not many people around to help if something goes wrong). Needless to say that the data has shown that companies that use feature flags do indeed release software often and at every hour of the day.
Cheers for a better quality of life after work hours with feature flags! Try Split and feature flags for free.
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
At Split, we “dogfood” our own product in so many ways. Our engineering and product teams are using Split nearly every day. It’s how we make Split better.
A/B testing is a powerful tool for learning about your users, understanding your features’ impact, and making informed business decisions. To ensure you make the best decisions and are extracting the most insights from your experiments, some experimental design guidelines are essential. These guidelines can be cumbersome or confusing at…
Feature flags provide so much for software organizations: they allow teams to separate code deployment from feature release, test in production, run experiments, and more. However, some rules apply to the feature flagging process that are easy for teams to overlook. I’ve gathered the best practices of feature flags from…