Marko Vušak presents Fun with feature flags

Feature is a set of behaviours that brings business value to the application. Feature flags are parts of code that enable us to switch some functionality on and off. They can be stored in code, configuration files, databases or some remote location. This sounds like an unnecessary complication… Why should I consider this

1. Enables passive testing of the feature code which means it reduces the chance of shipping broken build to production.
2. Each part that you implement will be branched out of develop, master, main or whatever is your latest branch which means early detection if something is messing with your feature.
3. Switching the feature on/off depending on your environment.
4. Switching the feature off quickly if something goes wrong after the production.
5. You can ship your feature parts in an incremental way hidden to production which reduces the chance of rebase hell.
6. Reduces the cognitive load on developers because they will not have to worry about a lot of changes at once while deploying the feature.

Sorry guys, Big bang deployment has been canceled.

Since I am mostly working with PHP and Symfony framework I will focus my examples on those two. However there are few approaches to solve this problem.

Approach number 1: Flag is in the application

The simplest example of feature flag is a switch in a code that will allow us to trigger some feature or to bypass it. And it looks like this:

Feature flag in code

By changing the value you decide which of the features will be active. Since I mentioned this post will also include the Symfony framework it also means that we will have another mechanism at the disposal, the dependancy injection container.

This gave us the opportunity to create something like this in a controller or in a service:

And inject it through the dependency injection container like this:

And then we can configure the value for each of our environments in different configuration files like this:

or directly on machine in each environment variable like this

This approach is probably the fastest performance wise but it requires an application redeploy for each change.

Approach 2: Store the flag in some storage

As the name says we are going to store the flag value in some storage(MySQL, PostgreSQL, Redis, Memcached) and read the value from there. While this approach offers the deployless option to change the flag value it also has some drawbacks. It is slower than storing the value in code and you risk overloading the storage server if you have higher traffic because for every place where you are reading the flag value you will need to go in the storage and fetch the value. And for the last drawback for each change you will need to connect to your storage and write some kind of a query to update the value.

Approach 3: Store the flag in a remote system and sync it to your app

This is the most complex approach to implement but can have the greatest benefits especially if you have a large app which takes a while to get deployed. For a large number of apps this approach is a simple overkill but let’s go over it.
Step 1: You have some system that can store and propagate this kind of a thing to your app, for example Unleash that is incorporated in Gitlab (this is not an Gitlab ad, I am showing this example because this is the only out of the box solution I used that has Version control and feature flags bundled together):

Step 2: You need a syncing mechanism. If you use Gitlabs official package it will work in a way that it will ping Gitlabs Unleash API whenever it wants to check the value.
Step 3: Configure Unleash SDK to cache values for some period or implement your caching mechanism since fetching Feature flag on every request can be rather slow. However implementing your own cache for this will likely strip you of canary release option.

Conclusion

There are cases when feature branches will make more sense than continous deployment but in most cases hiding stuff behind feature flags will make your life much easier because you will not have to maintain stuff for days, weeks or even months before it ends up in production. As shown in examples there are multiple approaches to implement them and I hope you will find one that fits your needs.