Next Level Release Management Using Feature Flags

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
   

   View Slide

2. ABOUT
   THIS TALK
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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.
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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?
    

    View Slide

13. BETTER BETA TESTING
    User’s can beta test features on
    the live system without having to
    navigate to a beta subdomain.
    Why?
    

    View Slide

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?
    

    View Slide

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?
    

    View Slide

16. FEWER REASONS TO NOT SHIP
    Shipophobia is real. This
    discipline provides a much
    gentler glide-path to getting
    features out to users.
    Why?
    

    View Slide

17. ENCOURAGE EXPERIMENTATION
    Your biggest population of users
    is in production, therefore, it’s the
    best place to get the most useful
    feedback.
    Why?
    

    View Slide

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?
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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/
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide