Feature Flag Driven Development

This story will share knowledge around feature-flag driven releases, explore benefits of feature flags and how to use them.

Photo by Arthur Mazi on Unsplash

This story is based on a project where I was using LaunchDarkly to handle feature flags. LaunchDarkly is 3rd party tool providing nice control over feature flags and you can easily integrate into your application. It provides a nice dashboard where you can manage your feature flags with different environments testing , staging and production .

Lets me first explain different categories of feature flags provided by LaunchDarkly

• Feature flags true/false — Thats general feature flag to enable and disable a feature and it’s used most of the time.
• Features flags with defined values — That feature flag provides different predefined values that you define against a the feature. Using those defined values You can choose different implementations of a feature or UI based on what value is being provided from feature flag. E.g In our project we created a feature flag for navigation to see which navigation is used the most with predefined values Drawer AND Bottom

Flags Handling Mechanism

Whenever you build a feature it must be under a feature flag keeping the following points in mind.

• When you create a flag, you must set the default value in your code for that flag which must be false in most of the cases. If your flags have predefined values you can choose which one should be default behaviour. Flags actual values are fetched from backend on start of app, until you have not read those from backend you must set such default values.
• When latest values are fetched from backend they must be preserved on app side to keep state/snapshot of the flags in the database for offline support and for the time frame of before fetching new updates.
• While checking for a flag you must give preference to previous fetched values stored in database, flags are less likely to change quickly.
• If you have a flag which is more often to change you must handle live updates of that flag. i.e You must listen for flag changes when the app is running in foreground and reflect on those changes while the user is on your app.
• When flag changes on fly, considering user is using the app, you must navigate the user nicely from the feature stating the feature is disabled or if new feature gets active which user will notice right away then you must provide onboarding flows/steps for nice transition for the user, of -course it all depends upon situation, use-case and need
• When you build a feature under a feature flag, you should make sure everything is disable under that feature flag for that particular feature . E.g all networking calls, all UI displaces, any background process related to the feature because When the flag is turned false there must be no related code running in any case.
• You must have flags supported for different environments testing, staging and production in order to support testing and reduce risk.

Flag configurations

We should have some configurations in place so that we can easily manage feature flags and can set the rules controlling the visibility of features as per need using parameters.

Parameters Information

We must have meta information of the user on the server or third party which is handling feature flags on cloud so that we can enable/disableas when we want. E,g we must provide following basic parameters to the server or third party when user launch the app or comes from background to foreground.

• app version — that’s the version of the app the user is using.
• app brand — the brand of the app, usually we have multiple brands to handle and we want to enable some features on one brand and hide in the other brand.
• countryCode — the country code that user belongs to is also helpful , it’s also need base, in our project we have logic around country codes within brands, we enabled features for specific country within brands
• Any other parameter that you think must be used in configurations of feature flags

Benefits of Feature Flagging

- Continues Feature delivery/ Iterative Improvements

The Biggest benefits of feature flag is it enables you to release features quick, gather feedback, improve, iterate over feature and redeploy

- Risk Management

Feature flags gives you control on disabling a feature after the release, if you encounter some issue in feature after releasing it to production, you find out that you can not fix it immediately and it might have huge impact if that issue stays in production. You can disable that feature using feature flag and fix the issue, release new build and enable feature flag again for latest version. Remember you must still disable on older version of the app because older version still have that issue, for that version parameter comes in play to use in enabling and disabling of feature flags.

- Partial and incremental Rollout

As I mentioned before about feature flags with defined sets of values , where you know different defined values will be provided, in LaunchDarkly you can manage percentage with each of the values e.g you want to roll 20% 60% and 20% for each of the three defined values for a flag. It allows you to release a feature to a small segment of users, check the impact, decide and increase the percentage whenever you want, enabling you to release a feature gradually, minimising the impact that the feature could have if it was released at once to all users.

E.g We created a feature flag named feature_chat_service with defined values of stomp and twillio , As we released recently twillio and didn’t want to enable for all users at once so we set 10% for twillio chat service and 90% for stomp chat service, so we can gradually started increasing the percentage after analysing and monitoring if everything is working as expected.

- A/B Testing

You can also use Feature flags with a defined set of values for A/B testing. If you want to test two or more sets of UIs or any service you can define values for those different sets in LaunchDarkly against the feature flag and use those defined values to show corresponding UI or use corresponding service based on your need. Then on LaunchDarkly you can define percentage rollout to set each value equal proportional percentage e.g 50% if you have both values.

E.g We wanted to test if DrawerNavigaiton or BottomNavigation is being used the most, for that we created a feature flag on LaunchDarkly named feature_app_main_navigation and defined two values drawer and bottom . Then in the App showed corresponding navigation based on the provided value, and on LaunchDarkly set the rollout percentage to be 50% for both values.

- Scheduling

LaunchDarkly provides a mechanism where you can control your deployment and schedule your features as per your need whenever you want. E.g If you have implemented a feature which needs to appear during an event you can set the scheduler/ timestamp and it will be enabled at that time.

- Upgrade Feature

Upgrade Interstitial feature can completely be implemented via LaunchDarkly feature flag. You can provide different conditions/rules over dashboard against the flag, these different rules will be based on app version describing when to show upgrade interstitial to the user, you do not need to explicitly implement any service on your backend to achieve this common feature.

Testing capability?

Testing feature flags must be done based on environments testing , staging and production . For one feature flag each environment configuration will be independent of the other environment so that feature flags can be tested in the designated environment before moving to other environments.LaunchDarkly provides these three environments.

Hope it was helpful :)

Follow for more stories on Android topics and 👏 if you liked it

— — — — — — — — — — — — — —

GitHub | LinkedIn | Twitter