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.
The design of your application can define its success; therefore, as a developer, you need to think about how to organize your CSS to have the greatest impact. The traditional way to organize CSS files in your React app is to import them into each component that is using that…
Why build or buy a robust feature flags as a service platform when you could just implement a simple toggling mechanism as a one-off and be done with it?
Blind spots have a way of coming back to bite you down the road. When building software, the size of that “bite” grows exponentially with time.