How Feature Flags have upgraded our workflow
To start, what are Feature Flags? Feature Flags in their most simplistic form are a toggle that your team has control over to turn on and off features in production, ideally without needing to push code.
How we implemented Feature Flags
We started by outlining what our goals were for Feature Flags, and to start our primary goal was to stabilize our release process by allowing us to QA in production.
We can all be honest, it does not matter how many beta or staging environments you set up, at the end of the day nothing acts like production. This is risky when you are an ecommerce site.
We stumbled on opensoft/rollout
, this fit our needs
of being able to actively toggle feature in production and it allowed us to use Redis as our feature flag storage.
Redis is a great fit for this.
We could store all our rules and states in the database, but that means for every user we would need to do a DB hit to check if a certain feature is available for them. At scale, this becomes a nightmare and a great way to lock up your DB.
Redis, is built for this, and we already use it for our caching layer. We know it works when we throw Black Friday traffic at it, handling feature flags will be no problem. The added benefit of this is we don't need to pre-register our features in the database. When the first user hits a new feature flag it is automatically registered in Redis as deactivated. This eases any dev or PM burden of ensuring flags are registered correctly.
We threw a wrapper around opensoft/rollout
(a fork of Jaspaul/laravel-rollout
) to make usage as simple as possible
and we built out an internal API for our Vue frontend to communicate with.
Usage
As a developer, all you need to do is wrap your code in a Rollout::isActive('feature')
and the rest will be handled
you. That sounds simple and it is!
The goal of the project was to ensure the feature flags were as easy as possible for developers to implement without having to worry about registering them in the database, ensuring all envirnoments have that new feature flag, etc. So when a feature flag is hit we automatically register the feature flag and mark it as disabled.
There are of course other ways to interact with the feature flag depending on the code you are working on. For example, we have a vue wrapper, a blade directive, and of course the above Facade.
Vue Wrapper:
<v-FeatureFlag :name="'show-size'">
<p class="text-sm font-light">
{{ size() }}
</p>
</v-FeatureFlag>
Blade Directive:
@rollout('show-size')
<p class="text-sm font-light">
Size
</p>
@endrollout
How it has changed our workflow
Feature flags were definitely the highlight of 2022, they fundamentally changed the way we work as a development team and for the better. No more long lived feature branches that have constant conflicts, and no more fixing those millions of conflicts.
Our workflow now is to push smaller code pieces that may be broken to production for us and QA to test in the live environment. We had to get comfortable pushing potentially broken code to production and QA had to get comfortable QAing in a live environment. However, we now no longer need to try to replicate the production environment (that we all know is impossible), the quality of our releases has increased fundamentally, deploying to production is a lot less scary than it used to be, and we can toggle third party integrations off with a simple switch when and if they decide to go down.