Breaking down a big feature to epics and stories is always tricky. Then you have sub-stories making the process complicated. If you could deploy the finished task that delivers value to the business it would help. Enter feature flags, using this you can deploy your code to production behind a gate. Code and feature are on production but not fully released to everyone.
This post is going to help you adjust your mental model for getting more benefits with feature flags.
Switches image from pixabay
Why use feature flags?
Have you ever faced a situation that you need to deploy an epic but it is not possible as it is 80% completed? It is an epic that has to be “released” all or nothing. That is where the power of the feature flag comes into play. You can deploy (not release to everyone) each new value added to production. The trick here is to put it behind a simple logic like if email ends in @yourcompany.com. You can check a minimal code example.
You have to separate the technical deployment process from the business process of releasing a new feature.
How to use feature flags?
Feature switch, feature toggle are some of the other names of feature flags. It can be effortless like if the logged in user’s email is in our white-list we show this form. It can even be a feature that shows up when you add a specific cookie with a defined value in the browser. It can be highly orchestrated too with the use of a SAAS for feature flags. Launch Darkly is a feature flag as a service company. You can use it if you have the time and resource to invest in it.
Any path you take simple or complex the result is you have control over who can access a new feature. The feature is not released to everyone. The difference is how to activate/deactivate a feature flag. It can be as easy as clicking a checkbox or doing another deployment to open up a feature to everyone.
My suggestion is to start small, do an if condition in code and start experimenting. If it works well try other ways like a white-list or even a special cookie from the browser.
Advantages of feature flags
There are many advantages of using feature flags in production. Lets list down a few highlights:
- Ability to test a feature on production in private with a select group of users.
- Ability to easily add or remove users who can use that feature.
- The confidence of releasing near bug-free features. Software engineers and QA can test on production even multiple times. Release the feature after bug fixes only when they are confident.
- There will be lesser code conflicts. When the task is complete, code changes are merged to the main branch before/after deployment. This also saves some valuable development time.
- The benefit of experimenting some things to a white-list of people in production. This can even lead to good feedback and positive changes.
Conclusion
You can deploy even small tasks to production with a proper use of feature flags. Think about adding value to the customer and deploying often. Test on production and when you are confident release it to everyone. Always remember Deployment != Release. Happy Feature flagging!
Originally published at geshan.com.np.
Top comments (2)
Thanks for your post! Feature flags can be really useful if used properly. Though it's not all happiness and I think, that the article would be more complete if disadvantages would have been mentioned too. Like sometimes ugly code or the danger of activating incomplete, untested features in production.
For those who want to go deeper in the world feature flags/toggles, here is a very deep article by Martin Fowler.
Agreed, generally if you have a rule to clean up when opening the feature to everyone it can be managed well. Thanks!