By Asa Schachar
From CI/CD, to deployments, to killer user experiences, feature flags help you build confidently and rollout gradually to minimize risk. But knowing where to start with integrating feature flags into your development cycle can be difficult.
I’m Asa, Developer Advocate at Optimizely. In part two of this blog series, I’ll cover three areas where you can integrate feature flagging into your build and release processes to help you roll out features, safely. Catch up on part one of the series here.
Let’s get started!
1. Down with long technical design phases! Long live incremental feature flags!
Problem: long technical design phase
As you advance your career as an engineer, you start working on larger features that are progressively more complicated, touching many different areas of the codebase. For these larger, more complex solutions, engineers often spend a lot of time understanding the components that the new feature will touch, and try to plan the changes in interfaces, functions, and components necessary for the full feature.
This amounts to a lengthy technical design phase where engineers are tasked with deciphering an entire system inside and out.
Ok solution: modularize to merge components independently
Instead of trying to fit everything in your head all at once, one common pattern is to break large systems into smaller, more modular chunks. Focusing on smaller pieces allows you to merge components independently without breaking the codebase (ex: start with building blocks in unit functions and components) and focus on getting the feature right from the ground up.
But by breaking a large initiative into chunks, you’re more likely to lose sight of the bigger picture goal. There have been countless times when I think I’ve nailed the perfect interface for a foundational function or API only to realize, after building a component to use it, the interface is unusable.
Also, this level of orchestration requires knowing in advance exactly how you’re going to build the full feature, which goes against modern agile software development. It’s nearly impossible to plan perfectly from the ground up while also adapting to new and changing requirements of today’s fast-paced software development lifecycle.
Better solution: incrementally improve with feature flags
Instead of making each component perfect before moving to the next, you can put all the pieces behind a feature flag and iteratively improve the feature as a whole. When you see the entire picture in production all at once, you’re more likely to get the feature up and running faster, and get the component boundaries right when modularizing your feature the first time.
You’re also able to see how everything functions together in the system, and have a better perspective should any edge cases arise. For your coworkers, the entire picture of the feature provides valuable context for faster code reviews. With this insight, they’re able to help you find better abstractions and interfaces, ultimately making you a stronger engineer who can deliver complex features faster.
2. Down with stressful hotfixes! Long live smooth rollbacks!
Problem: unexpected emergency bug
Today’s world is super-connected. It’s very likely the software you’re building will be used by people all over the world with users across all timezones. But this level of exposure also sets you up for something to go wrong at inopportune times, like after work, or worse, while you’re sleeping. When you’re woken up in the middle of the night because of an issue, it’s probably urgent.
These situations are usually extremely stressful because:
- You have to debug the situation fast—every second counts
- You have to make business and technical tradeoffs quickly
- You have to bypass standard engineering procedures with something like a hotfix
- You likely do this all alone in the middle of the night with little practice
- You have to address customer-facing issues quickly while under pressure
Wouldn’t it be nice to avoid this entirely?
Ok solution: become a seasoned on-call engineer with hotfix experience
The upside with hotfixes is the more you handle them, the better you get. However, emergencies are unplanned and usually happen infrequently, so it’s hard to practice and improve. Furthermore, I bet you’d prefer a full night’s sleep anyway, so keep reading 🙂
Better solution: rollback features with toggles
By wrapping your feature in a feature flag and using a system that can remotely control who gets access via a rollout, you can easily and effectively rollback the feature during emergencies. With a rollback, you can quickly resolve the problem by turning off access to the feature and buy yourself more time to determine the issue and develop a proper fix.
Additionally, with feature flags, you don’t have to rollback to a previous version of an entire application, reversing the work of several engineers at once and halting an entire team’s productivity. Instead, you can rollback just the feature in question, affecting only those engineers working on the feature.
Bottom line: sleep better with feature flags 😴
3. Down with deploy and pray! Long live rolling out confidently with feature flags!
Problem: impossible to plan for every launch scenario
Deploying code to production is truly exciting. In seconds, the things you’ve built are used across the world. However, with the power of deploying code to production comes the possibility of breaking people’s experiences and angering users.
While your team, manager, and company are all relying on the successful launch of your feature, it’s impossible to account for all possible bad outcomes and be 100% prepared.
Ok solution: become a better engineer
Once you have years of engineering experience, with hundreds of launches under your belt, it’s easier to think of uncommon scenarios and predict all the possible bad outcomes. Or, a faster route is to gain more confidence in your code with automated tests. However, this is still prone to errors.
Better solution: test in production with feature flags
With feature flags, you separate the process of deploying your feature from actually showing it to users. So, instead of launching your feature all at once, you can slowly roll it out, gaining confidence as you introduce it to 100% of your users.
This approach is especially useful when you want to launch on a particular date, and it saves you from the stressful hotfixes mentioned above.
Let me know what you think!
I hope these three wins help you use feature flags for smoother deployments, and I’d love to hear how it goes. Reach out to me in our slack community or tell me on Twitter at @asametrical how you’ll use feature flags in your build and deploy systems.
If you enjoyed this post, stay tuned for the next in this series on feature flag use cases, and sign up for Optimizely Rollouts, a free product that allows you to create and manage feature flags and experiments!
4
1377
