A brief history
Deploying feature and deploying code is generally associated as being one operation. When developpers want to add something to a website or an app, they add code.
From this assumption, people have improved the way they manage their code and created workflows that facilitate the deployment of their apps. One common example is the Gitflow. When using Gitflow, only the commits that exist on the
main branch are deployed to production.
While this kind of flow make sense in some situation, we can question the strong link between deploying code and deploying features. Do we really need to couple the notion of deploying code to production and to rollout new features to the audience?
Separating the notions
It’s not necessary to couple code deployments and feature releases.
For instance, in trunk base development, you deploy code as soon as you can. Deploying so often means that the production application contains code for features that are not finished yet. Obviously the audience should not have access to something that does not properly work.
How to prevent your audience from accessing unfinished features? using feature flags.
A feature flag is basically a toggle: an on/off button. When on
on, the user will see the new feature. When on
off, they won’t.
In a codebase, it’s as simple as a condition:
From this simple concept of showing a feature based on a condition, it’s possible to create an interesting toolkit: under which constraints should the flag show the new dashboard? To how many user?
The benefits of such system are multiple, and quite interesting:
- Separate code deployment from feature releases
- Easy rollbacks when unexpected bugs happen
- Makes possible testing in production (using targeting criteria)
- Gradual rollout (a percentage of the audience)
- Makes A/B testing possible (feature flags can have other values than
- Time based rollout (feature flags can be activated at a given date)