Feature Flags for Mobile Development

In this talk, I went through the concept of Feature Flagging systems. Trying to explain what Feature Flags are, why are they useful for product development teams, and how an Android engineer can build a Feature Flagging system.
The source code that shows the architecture implementation of feature flags is here: https://github.com/rygelouv/FeatureFlags

Transcript

1. Dakar Ruby Brigade Feature Flags For Mobile Development 1 Rygel Louv By
2. Rygel Louv Software Engineer @rygelouv @rygellouv @rygel
3. What are Feature Flags? A feature flag is a mechanism that allows you to choose between different code paths in your system at runtime.
4. What are Feature Flags? Basically a simple if statement decision
5. What are Feature Flags? Basically a simple if statement decision
6. That’s it?
7. Feature Flags Ultimate Advantage Improves the Development process and Product Release management
8. Feature Flags Use Cases Decouple Development from Release For features that will take time to complete, instead of creating a long-living feature branch then struggling with merge hell, later on, you can use feature flags to push and deploy your code changes to production without affecting any existing functionality. The feature can then be activated whenever it is ready.
9. Feature Flags Use Cases Enable Continuous Delivery Feature flags are an integral part of continuous delivery. They allow engineers to decouple deployment from release and also place control of feature release into the hands of product management.
10. Feature Flags Use Cases Controlled Rollout and Production tests Make the feature available for subset of users and allow testing it in production and obtain valuable feedback.
11. Feature Flags Use Cases Canary Releases A canary release is a software testing technique used to reduce the risk of introducing a new software version into production by gradually rolling out the change to a small subset of users, before rolling it out to the entire platform/infrastructure.
12. Feature Flags Use Cases Safer Releases We can reduce the risks associated with rolling out a new feature using feature flags.
13. Feature Flags Use Cases Kill Switch When things don't go as planned with a feature in production, you can use feature flags to disable the feature till your engineering team can figure out what went wrong.
14. Feature Flags Use Cases A/B tests and Experiments Feature flags allow you to scientifically validate your product ideas. A good feature flagging system allows a product manager to slice and dice their userbase, establishing treatment and control groups for a feature based on various demographics.
15. Feature Flags Best Practices Use sensible naming convention In the absence of a naming convention, team members may end up naming flags with the same name and getting flags jumbled up. As a result, a team member may activate the wrong flag, potentially causing system interruptions.
16. Feature Flags Best Practices Incredibly Easy to add It must be incredibly easy to add a new feature flag. The easier that is, the more you will do it and the more you’ll benefit from them.
17. Feature Flags Best Practices: Management Scope Each Flag to single Team Each feature flag should be owned by a single team to avoid overlap in accountability. Always aim to have each flag owned by a clearly identified team. That team is responsible for driving the feature’s rollout, monitoring its performance, and retiring the flag when it’s time.
18. Feature Flags Best Practices: Management Feature Flags should have limited lifespan You should be intentional about removing flags once they have served their purpose. You need to remember to delete feature flags when they’re no longer in use or the feature changes.
19. Feature Flags Best Practices: Rollout Maintain Consistency Suppose User A visits your site, and your feature-flagging system decides that User A should see a specific feature (variation “on” of the feature). In that case, User A should continue to see this variation of the feature no matter how many times the flag is evaluated. Increasing the exposure to a broader user population should not affect the current specific exposure of variations to users—if a user experienced a feature when it ramped to 40%, that user should continue to see it as it ramps to 60%, 80%, and so on.
20. Feature Flags Best Practices: Implementation Your feature flagging system should not be on the critical path of your application. There needs to be a graceful degradation path so that in case of an outage, your system can continue to function. Don’t make the feature flagging system a potential single point of failure
21. Feature Flags Best Practices: Implementation Build a wrapper around your feature flagging framework There are two parts to implementing a feature flag: the evaluation and the logic. You should separate the logic from the evaluation because it prevents the details of your feature flagging implementation from leaking all over your codebase.
22. Feature Flags Implementation in Mobile development Why are they critical for mobile development? Mobile does not have the same flexibility as backend or web. Stand-alone mobile apps are harder to update. You also have to take into account Play Store and App Store review time for every single update
23. Feature Flags Implementation in Mobile development Provisioning: Debug (Development) Mode You want predictable, easy access to feature flags. Can be stored locally using Shared Preferences, Local Files or local Databases. They should be updatable at runtime Provisioning: Release (Staging/Production) Mode You want to be able to remotely toggle the feature flags. Hence they should also be remotely available, which is typically provided by a framework
24. Feature Flags Implementation in Mobile development Third party services Firebase Remote Config LaunchDarkly Etc Server flags User object flags returned by your backend
25. Feature Flags Implementation in Mobile development Feature Flags catalogs Features: application functionalities Debug Configs: application dev/debug settings. Use to facilitate debugging and maintenance.
26. Feature Flags Implementation in Mobile development Debug Menu Hence there should be some screen in the app where you can see the current state of all feature flags and toggle them. Ideally, this UI should even be auto-generated
27. Feature Flags Implementation in Mobile development Complexity Feature flags can bring a lot of complexity in your codebase Use booleans to make them simple Use Strategy Pattern to avoid complex blocks of if statements Use inversion of decision to reduce complexity Decouple decision point from decision logic
28. Feature Flags Implementation in Mobile development Testing It should be able to easily toggle feature flags on/off in automated tests Feature flag code must be tested
29. Feature Flags Implementation in Mobile development Testing In summary, feature flags should be: • very easy to add • locally and remotely available • binary in value • cater for both features and test settings • con fi gurable for automated tests • agnostic of the used remote feature fl ag tool
30. Feature Flags Implementation in Mobile development Architecture Implementation https://github.com/rygelouv/FeatureFlags
31. Questions?
32. Thank you @rygelouv @rygellouv @rygel
33. Sources https://jeroenmols.com/blog/2019/08/13/featureflags/ https://martinfowler.com/articles/feature-toggles.html https://www.split.io/guides/feature-flags/ https://www.split.io/blog/dos-and-donts-of-feature-flags/ https://instabug.com/blog/soft-launch-dark-launch-and-canary-release-for-mobile-apps/ https://instabug.com/blog/top-mobile-feature-flag-tools/ https://blog.bitrise.io/post/a-guide-to-feature-flags-in-mobile-development https://www.holdapp.com/blog/how-to-implement-feature-flags https://medium.com/@Invoice2go/how-we-implement-feature-toggle-on-android-86bb1505ec6c