Next Level Release Management Using Feature Flags

The Thoughtworks Technology Radar (http://thght.works/25OCOpn) recently highlighted “Decoupling features from releases” as the top priority for “Techniques” to adopt.

With deploying an application getting trickier and trickier, as the features we build get ever more complex, this is something we should definitely pay attention to.

In this talk, I will be showing you how you can level up your release management and deployment strategies using feature flags, and why they could just be a future core principle in modern app development.

Transcript

1. NEXT LEVEL RELEASE MANAGEMENT W I T H T H E P O W E R O F F E A T U R E F L A G S B E S P O K E S O F T W A R E D E V E L O P M E N T
2. ABOUT THIS TALK
3. ABOUT THIS TALK Where we are. Where we could go Release Mgmt Overview Solving a crucial problem for software releases Feature Flags Overview How will they make our lives, and our customer’s live’s better? Why Feature Flags? Cool techniques, and even cooler pitfalls. Advanced Uses & Gotchas
4. RELEASE MGMT OVERVIEW W H E R E W E A R E , W H E R E W E C O U L D G O. B E S P O K E S O F T W A R E D E V E L O P M E N T
5. RELEASE MANAGEMENT More Complexity Complexity is still on the rise, especially with technology. This complexity has a direct correlation to business risk. Less Time Competition and budgets are tight. We have to deliver better systems sooner. More Features Modern day apps simply do more, even if those features aren't visible to users
6. RELEASE MANAGEMENT Merge Reintegration Nightmares Long lived branches? Merge Branches? Multiple Features In Dev Concurrently Bigger teams mean more features are WIP on different components of a system Different Lengths Of Time To Complete Features don’t take the same amount of time to complete, nor do they all start or end at the same time.
7. RELEASE MANAGEMENT Experiment vs Right 1st Time Experimentation and gathering feedback is perceived as costly, therefore increase pressure to get it right 1st time. Heavy Process vs Operational Detail The act of deployment is 100% tied to the concept of release. Expensive Deploys Coordination between ops, dev, marketing, sales
8. FEATURE FLAGS OVERVIEW SO LV I NG A C R U C I AL PR O BL EM FO R R E L E A SI NG SO F T WA R E B E S P O K E S O F T W A R E D E V E L O P M E N T
9. FEATURE FLAGS OVERVIEW H I G H L E V E L M E C H A N I C S Actors Enable or disable entirely Toggle for users, components, etc Toggle for groups of actors, i.e. only power users Or a percentage of actors or groups Or a percentage of time, i.e. only during peak times On/Off Switch Groups of Actors Percentage of Actors Percentage of Time
10. SIMPLE DEMO FEATURE FL AGS I N ACTI ON B E S P O K E S O F T W A R E D E V E L O P M E N T
11. WHY FEATURE FLAGS? W H AT ’S T H E PAY O F F ? B E S P O K E S O F T W A R E D E V E L O P M E N T
12. BETTER CONTINUOUS DELIVERY Move away from “Does everything work as expected?” to “Is the build clean?”. Less pressure to make sure everything is perfect in lockstep. Why?
13. BETTER BETA TESTING User’s can beta test features on the live system without having to navigate to a beta subdomain. Why?
14. LOWER RELEASE RISK If something doesn't work, no need to rollback a whole release, just switch the feature off and try again. Why?
15. LOWER INFRASTRUCTURE COSTS Now possible to open a feature up only to internal QA to test. (if your org is OK with that) Why?
16. FEWER REASONS TO NOT SHIP Shipophobia is real. This discipline provides a much gentler glide-path to getting features out to users. Why?
17. ENCOURAGE EXPERIMENTATION Your biggest population of users is in production, therefore, it’s the best place to get the most useful feedback. Why?
18. DECOUPLE RELEASES FROM DEPLOYS A deploy should be about refreshing the codebase. Conflating it with releasing updated software complicates matters and introduces bureaucracy. Why?
19. ADVANCED USES AND GOTCHAS NI CE TR I CKS, SU BTL E TR APS B E S P O K E S O F T W A R E D E V E L O P M E N T
20. PHASE IN LIKE INTERCOM https://blog.intercom.io/why-continuous-deployment-just-keeps-on-giving/ Build 01 Staff-Only 02 Beta-Testers 03 Everyone 04
21. Step 1 Confirm terminality Step 2 Disable feature for new signups Step 3 Divide users and dabblers. Disable for dabblers. Step 4 Announce EOL to rest of users PHASE OUT LIKE INTERCOM https://blog.intercom.io/how-to-sunset-a-feature/
22. USE HOOKS IN AN EXCEPTION TRACKER LIKE HONEYBADGER OR SENTRY TO SWITCH OFF BROKEN FEATURES Your app knows when things are broken. Give it the autonomy to act on that knowledge PROGRAMATICALLY DEGRADE
23. SAVE A ROUND TRIP BACK TO THE SERVER But, hey, still double check on the backend like any normal validation, ok? PUSH FLAGS TO FRONTEND
24. TIER PRODUCTS * * Adult supervision required Private Plan 10$ per month Email delivered on Tuesdays 100 cat pictures Runs on a spare Arduino we have lying around Kinda OK Features, I guess… Get Private Plan Business Plan 20$ per month Real time email 100 cat pictures, plus baby sloths Runs on VM on our secretary’s PC Awesome buttons that do stuff. Get Business Plan Mega Plan 50$ per month Time machine to send emails before they exist Cats, baby sloths, and red pandas. Runs on all the clouds Your own dedicated AI core Get Mega Plan
25. ‹#› Lion presentation to: PowerBrush Page: GOTCHAS WATCH OUT FOR THESE EASY PITFALLS CI builds *have* to be green Getting this wrong is a sure-fire way to torpedo getting this accepted as part of your org culture Interdependent Features don't leak bugs Make sure that cross-concern features are fully tested. A bug intro’d in a partially complete feature might break a live feature. Respect data migrations Be extra careful when introducing data model changes during deploys. This will always be higher risk than normal
26. THANKS YOU’RE AWESOME B E S P O K E S O F T W A R E D E V E L O P M E N T @ W E _ A R E _ Z E R O _ O N E W W W . Z E R O - O N E . I O H E L L O @ Z E R O - O N E . I O