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.
With feature flags, you can control the percentage allocation of users you want to be exposed to a specific feature. This process provides risk mitigation and confirms both usability and scalability. Canary releases, or controlled rollouts, serve as an added layer of protection in case something goes wrong. What is…
Feature flagging is a technique development teams deploy to enable easy switches between codepaths in their systems, at runtime. In simpler terms, they’re control structures that toggle on and off the code inside them. Dev teams use feature flags for a wide variety of purposes, from canary releases to A/B…
If our organizations want to survive this period of political and economic uncertainty, they must be able to move with speed and adaptability.