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.
Staging environments aren’t great reflections of reality. Instead, investing in CI/CD, feature flags, and QA can skip your code straight to production.
Great teams don’t run experiments to prove they are right; they run them to answer questions. Guard against wishful thinking and hidden biases with this shortlist of core principles for productive online controlled experiments. (Video, transcript and screenshots from talk given at Pinterest HQ on September 13, 2019)
Last week we walked The Path To Progressive Delivery. This week, we go deeper. What goals can we meet with the Four Shades of Progressive Delivery? After you read or watch this week’s episode, you will be better equipped to choose a Progressive Delivery approach that works for you. My…