blog post banner image

Feature Flag Best Practices

Ann McArthur


What are Best Practices for Feature Flags

Feature flags, also known as feature toggles, are the best way for developers to ship new features with confidence. By wrapping a feature in a flag, software development and engineering teams can mitigate risk by rolling new code back if there are any bugs and use canary releases to gradually release them to their user base to gather feedback and test its impact. While there are several reasons to use feature flags, there are best practices that engineering teams should employ when using them.

Table of contents:

  • Fast Deployment
  • Percentage Based Rollouts
  • Portability
  • Why isn’t everyone using feature flags
  • The benefits of feature flags
  • Improving your workflow

Fast Deployment

There are several use cases for feature flags. When building DevCycle, our software developers and engineers were excited to use feature flags in Terraform since it would allow us to deploy everything as fast as possible.

You can deploy code and use Terraform to say, here's the infrastructure for a new service feature flag. That code can automatically be on prod but the infrastructure can be locked behind a feature flag. This means we can’t create the physical infrastructure until the feature switch is turned on. From there you can run Atlantis and Atlantis will create that infrastructure. This creates a very safe release since you can have code in main that's locked behind a feature flag meaning Atlantis won't touch it. 

From there, you can have it deploy automatically and set up everything from feature flags, cloud infrastructure, and deployments, to be much smoother and faster, plus they can be turned on and off almost instantaneously. 

For example, to revert a deploy you have to check several things on your previous branch. With feature flags, a team member can specify the feature they want to enable. Say you have a new API service. You’re going to enable the public API and then run a deploy. If it breaks, you can turn off the public API, rerun that exact same deploy and it will only disable the API. This will save you so much time since you no longer have to check out previous branches, overwrite previous Terraform config and deal with checkout problems. 

Percentage Based Rollouts

Another way to use feature flags is with betas. It's a good practice to use percentage-based rollouts to see how something actually works with a group of users. With feature flags, you can specify that a certain percentage of users should have access to an API. 

Say a client wants a new feature. You can create that new feature, then only enable it for them meaning that they are the only ones who are going to ever have potential negative exposure since they requested it. Alternatively, you can block behind custom features. Say a client wants a new feature, you can lock the feature behind a feature flag so only that client gets access. This means the code is still in main and you don't have to have an extensive if branch. Instead, you can simply check if the client's feature flag is enabled. Anyone from product, marketing, or engineering teams can control the percentage-based rollout. This could also help minimize the workload for developers by having a product team determine the rollout.


Feature flags are portable, think of them as booleans as a service. You can lock anything anywhere behind any feature. Boolean natively in computer terms is a single bit. Every single computer platform has room for a single bit.

You can fit the concept of a feature flag in a boolean anywhere. You can have it on a phone, a computer, tablet, PlayStation, Xbox and have it on embedded devices. There are several places that release toggles aren't used because they were previously thought of as being very heavy, and you would have to implement it yourself and build your own infrastructure. 

By providing feature flags through DevCycle, software developers and engineers can make a really low-level library that calls out to DevCycle then get a one or zero back. That’s how easy it is to get started with feature flags. 

Why isn’t everyone using feature flags?

With all the benefits feature flags have to offer, why isn’t everyone using them? Feature toggles are new, and new can be “scary”. Using anything that is new on the market can prevent people from wanting to try it since they want to see it succeed with others first.

However, you won’t know until you give something a try. Take standing desks. In 2007, they started being advertised, but not many people got them. Now so many people are focused on ergonomics and the companies that invested early in getting standing desks are much better off since they're now preaching that they’ve been investing in their companies’ ergonomics for so long.  

What are the benefits?

Feature flags are new, but they’re incredibly helpful. You can ship faster, roll things back, use feature flags as a kill switch and potentially save yourself a lot of grief. Adding feature flags into your release cycle is a culture and workflow change, but it makes developers’ lives much easier.  They can lock everything behind a feature flag and just give code when they run everything since if it works they can enable it, and if it doesn't work they simply turn it back off. 

Get Started with DevCycle Today

DevCycle is an easy way to deal with feature flag management and keeps them organized so you can ensure you’re using best practices when releasing your feature flags and creating the best user experience possible.

Written By

Ann McArthur