Feature Flagging

This short presentation shows how we used feature flagging at NPG to enable some really cool things - continuous deployment, a/b testing, canary releases and replacing legacy applications to name a few...

This was presented to the engineering team at MOO on 13-May-2016 in London.

Transcript

1. Feature Flagging What is it, and what can it do for you?
2. What Is Feature Flagging? a.k.a. Feature Bits, Flippers, Switches etc etc A software development technique/pattern which attempts to provide an alternative to maintaining multiple feature/release branches and can help a team to deliver new functionality to users rapidly but safely. https://en.wikipedia.org/wiki/Feature_toggle http://martinfowler.com/bliki/FeatureToggle.html http://martinfowler.com/articles/feature-toggles.html
3. What Feature Flagging Enabled...
4. Show/hide new features Show/hide broken/unfinished features Initially... Simple Things
7. But What Did That Enable? • Decouple feature release from deployment ◦ You don’t need to release everything in a big bang - put the code on the server, check it’s all ok (using the flags), then release the features to the users when you’re ready • Continuous deployment ◦ You can deploy unfinished features! They’re there, just switched off until they’re ready • You can test things with LIVE data ◦ TEST data is never as good as the real thing...
8. Getting a Little More Adventurous... A/B test new features/designs You’re already measuring the metrics/KPI’s you’re interested in right? Include a feature flag value into your metric matrix and you can compare the performance of a new design/feature using all the data you really care about by segmenting the data on that value.
9. A B
10. Taking Another Step... Progressively release experimental features Also known as “Canary releases” or “Stepped releases”. Release a new feature to a certain group of users or a percentage of users. Can be useful if you just want to get feedback from a select group, or if the new feature you’re releasing is risky and you want to watch the system impact as it goes out.
11. #winning Progressively replace legacy apps without touching the old code WE ACTUALLY DID THIS at Nature a number of times using these two tools: • Bandiera (github.com/springernature/bandiera) • Thundermole (github.com/springernature/thundermole) The basic strategy is to place a transparent (but programmable) proxy in front of both the legacy and new apps. Then selectively proxy to either of the two apps based on feature flag settings and domain logic in the new app (via an api call).
19. Simple Tools
20. Enable BIG Things
21. Bandiera https://github.com/springernature/bandiera
22. Bandiera • Feature flagging server • Simple UI and API • Programming language agnostic - it’s just HTTP and JSON • Client libraries already written for a few languages: ◦ Ruby ◦ Javascript/Node.js ◦ PHP
23. What Can It Do? • “Basic” ◦ Simple on/off for everyone • “User Group” ◦ A defined user role (i.e. Admins) could see a new feature ◦ A whitelist of email addresses could see a new feature • “Percentage” ◦ Roll a feature out to a percentage of your audience • “User Group” AND “Percentage” ◦ Combine the above
24. Demo
25. General Things to Consider... • Development ◦ Surround entire new features in ONE flag ◦ Use ONE flag PER FEATURE - don’t bunch a load of things together ◦ Give your feature flags SENSIBLE NAMES - makes using them much nicer ◦ DO use flags for positively enabling new features - i.e. show-new-search, show-article- metrics - means that the flag has to have a 'true' state in order for the new feature to be visible and the safe default is for them to be switched off ◦ DON'T use flags for suppressing new features - i.e. hide-new-search, hide-article- metrics - your feature flags should have a safe default. If Bandiera fails or a network error occurs between your app and Bandiera and you are using feature flags in this way, your new features will be switched on by default as they will no longer be hidden
26. General Things to Consider... • Testing - you’re going to want to test your feature/code right? ◦ Automated way to switch your flags on/off ◦ Write tests for both the on AND off state • Bugs ◦ Don’t bother with feature flagging bugs, if it’s something that HAS to go out, why add the complication • Cleanup as you go ◦ You WILL generate a LOT of feature flags - make it part of your sprint cycle to remove old feature flags from both your code and bandiera once something is live and it’s not about to go away
27. Thundermole https://github.com/springernature/thundermole
28. Thundermole A programmable routing proxy. Proxies or redirects requests based on an API response. Can support multiple APIs and routes at once.
30. Thundermole - More Info... • github.com/springernature/thundermole • cruft.io/posts/complex-routing-logic-with-thundermole/
31. Thanks