Feature flags: Your quickstart guide for why & when to use them
Feature flags are a simple development tool that is integral to unlocking the many benefits of Continuous Delivery. But what exactly are feature flags and when should you use them? Here’s everything you need to know to get started.
What are feature flags?
Feature flags are active, conditional branches in your codebase that determine the functionality that a user or team experiences in your application. In other words they are a glorified if-else statement. Feature flags allow you to hide functionality so that you can release it at a later time or release it conditionally. As a result, feature flags are great for running an experiment (think A/B testing), planning for a release, or de-risking technical operations when rolling out a new feature. Importantly, feature flags are not permanent; rather, you remove them from the codebase when the associated feature has been rolled out for all users or the experiment is concluded.
Why should you use feature flags?
Using feature flags as release toggles by hiding specific functionality for all or some users makes them integral to unlocking the many benefits of Continuous Delivery. Specifically, feature flags empower teams to ship partial features all the way to production without affecting users. They also help increase efficiency for delivery teams, improve business planning for upcoming releases, and can enable fast feedback collection from a smaller, trusted subset of users.
Technical benefits of feature flags
The biggest technical benefit of feature flags is that they make it easier to ship smaller iterations of features throughout the entire development process so that workstreams can occur in parallel. In doing so, they help reduce risk and increase delivery team productivity.
Let’s break this down. It’s important to note that the development process involves much more than just coding. It also includes at least several of the following:
- Planning and splitting up work
- Writing code
- Writing tests
- Checking functionality with QA
- Checking business results with a product owner
- Checking the design developed with the designer
- Peer reviewing the code with another developer
- Shipping the code and any configuration changes to production
- Briefly monitoring production after the code ships
- Turning on the feature for a subset of users/teams
Given all of these steps, the best way to make multiple changes in parallel without error is to introduce smaller changes. This is because smaller changes produce easier to understand functionality, more focused test plans, and fewer code merges or rebases (which happen whenever the upstream code is ahead of a developer’s local branch). Critically, as the amount of code changes increase, the risk associated in merging or rebasing code increases too, since there are more opportunities for developers to make a mistake that could create bugs or lead to downtime for customers. This risk is important to understand and we covered it in a previous post here.
Without feature flags we have big ole' risky deploys
In a world without feature flags, merging a working branch into the integration branch is often how software is shipped to production. Because partial changes cannot be hidden in production, the size, and complexity of these working branches is typically quite large and the branches are long lived. This introduces many additional opportunities for programmer error and all of those chances for individual errors accumulate together into the total risk for a release. Yikes.
Also in a world without feature flags, more development teams working on the product compound this problem. There are effectively often tiers of integration branches with each development team merging into a mid-tier feature branch and each team subsequently merging their feature branches into the integration branch that is then deployed to production. There is a higher quantity of upstream changes and even fewer shared context between the teams.
This is further compounded by the advent of a new business risk – release order. Without feature flags businesses are stuck with the task of guessing which feature branch will go to production first. They will guess wrong most of the time. It is incredibly easy to guess incorrectly because estimating large changes and accounting for interruptions or staffing issues is difficult. Every wrong guess delays all of the subsequent releases by the same amount of time the initial release was delayed. This is a relatively safe, but wildly expensive way to develop software.
Save us feature flags, you’re our only hope
Feature flags enable teams to do this better by allowing partial changes to be merged into the integration branch and shipped to production without affecting users. This is done in conjunction with teams planning smaller and smaller changes that map to shorter and shorter lived working branches. With very short lived working branches the chances of a code conflict requiring a merge is less likely. Also very simple changes tend to require far less context to merge into your working copy. It is often much more apparent what the intent of the changes are making the merges themselves simpler and less likely to produce a bug.
With multiple delivery teams, the smaller changes empowered by feature flags eliminate release order challenges entirely. Everything is completely done and available in production by default and the business can turn on the feature as soon as they are ready.
Business benefits of feature flags
Feature flags also deliver several business benefits. The first business benefit of feature flags is the ability to give smaller groups early access to features. These groups might be:
- Your own team, so they can find bugs before customers do
- Trusted customers who are part of an early access program through which they verify that the changes actually meet their requirements (without the risk of churn)
Second, feature flags allow you to decouple the software development process from other major business functions like sales, marketing, training, and support. This decoupling allows each of these teams to develop their own materials based on what exists in production rather than based on a roadmap of what will exist in the future. Shifting to what actually exists allows these teams to see work in progress to get a head start on documents, training materials, and even learning how to demo before the updates actually go live. It also ensures that the schedule for these activities won’t get pushed due to development delays.
When should you use feature flags?
You can use feature flags whenever you can break up a scope of work into meaningful chunks of functionality that can be delivered independently. For instance, with CRUD pages for a new resource in your application, you might have separate work for “create,” “read,” “update,” and “delete” pages all under the same feature flag. Ideally, your feature flags should encompass a marketable amount of functionality and ultimately produce working functionality in production. In other words, all changes should be production-ready.
Lastly, feature flags should have a limited lifespan, because even though they are inexpensive to create, they can be costly to maintain. The best approach is to get rid of feature flags once the functionality is complete and the feature is marketed to customers and turned on for everyone.
Ready to get started?
Interested in learning more about how you can get started with feature flags and Continuous Delivery in your organization? Contact Spaceship today to learn how we can help.