Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

ABOUT THIS TALK

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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?

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

LOWER RELEASE RISK If something doesn't work, no need to rollback a whole release, just switch the feature off and try again. Why?

Slide 15

Slide 15 text

LOWER INFRASTRUCTURE COSTS Now possible to open a feature up only to internal QA to test. (if your org is OK with that) Why?

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

DECOUPLE RELEASES FROM DEPLOYS A deploy should be about refreshing the codebase. Conflating it with releasing updated software complicates matters and introduces bureaucracy. Why?

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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/

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

‹#› 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

Slide 26

Slide 26 text

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