Day 11 - Feature Flags 1
Or What my engineer means when she says: "Do you want to release our <big feature> incrementally with feature flags?"
Or What my engineer means when she says:
Do you want to release our <big feature> incrementally with feature flags?
Yesterday we talked about different environments our app is running on, mainly:
Development environment (env).
Testing env.
Staging env.
and Production env.
What if Prod is not enough?
Now imagine you have a feature that works well on testing and staging environments but:
it's so big that you don't want to release it to everyone yet or
is just an idea and you want to gather feedback from real users or
is a variation of the current design and you want to compare its performance before enabling it for everyone
is only relevant for a portion of users (based on location, products they bought, membership type, behaviors, ...)
or many more cases where you need to release a piece of code only to a portion of your users (either at random, e.g. 5%, or targeted, e.g. all users based in Germany).
You can achieve some of the above with an if/else
clause in your code but what if you also:
want to "track" their behavior as well, and
in case it has any side effects, you want to "disable" the feature immediately and roll back the app to its previous version.
Well, feature flags are a software pattern to enable exactly these functionalities.
Feature flags are...
a software engineering technique that turns select functionality on and off during runtime, without deploying new code.
This enables teams to make changes without pushing additional code and allows for more controlled experimentation over the lifecycle of features.
In nature, they are still an "if statement", but the main keywords are, being able to do it in runtime, without deploying a new code, makes them more scalable and maintainable.
Let's keep today as an introduction for this lovely topic, especially if you are into A/B testing and incremental release, you'll love Feature Flags.
More on them coming tomorrow!