The word toggle has a variety of meanings: the pin passed through the eye of a rope to hold it in place, an on-off command, and in computer technology, a switch. Feature toggles are a great way for engineering teams to test new code and features in a live production environment without risking a full code deployment. They also provide a way to remotely rollback features that may be experiencing problems during user testing or causing latency spikes in the system.

Traditionally, when a new feature is ready for release it would have to be created on a separate code branch and then manually merged into trunk code for the rest of the application. Using feature toggles your development team can create a temporary branch with the new functionality and then release that branch to a subset of users (via either an Ops Toggle or Champagne Brunch) while they work on finishing up that code. Then once the feature is complete you can easily turn it on for the whole user base.

When creating feature toggles it’s important to consider how you’ll manage their configuration. While static configuration is preferable there are some cases where you need a more dynamic approach. This could be as simple as hardcoding a toggle in the source code, or more sophisticated such as an encoding in a preprocessor’s #ifdef feature, or via an entry in an external feature flag service. Whatever method you choose it’s best practice to name toggles in a meaningful way so anyone on your development team can understand what the toggle represents and what it does.