A toggle is a switch that lets you quickly change the status of something. You might see them in a door handle, on a light switch, or even in software like a keyboard’s caps lock key. They’re used to update preferences, settings, and other kinds of information. It’s important to use them wisely. When designing a toggle, make sure it has clear labels, delivers immediate results, and makes sense in your context.

When a team uses toggles in their release process they should be proactive about removing toggle configuration that is no longer needed. Doing so reduces the risk of unexpected regressions in a future version and makes it easier for teams to test their releases.

Savvy teams take care to only have toggle configuration living side-by-side in source control that they will actually use for production. This is typically paired with some type of centralized toggle management system which enables runtime re-configuration. This allows a CI/CD pipeline to dynamically override the toggle configuration and send a given release through one path or another. This is often done for Experiment Toggles or to implement a form of multivariate or A/B testing.

Toggle configuration is a powerful tool when implemented properly but it’s also dangerous if a team gets too greedy and creates an inventory of toggles that they never plan to use. This can slow down the cycle time for validation tests and negatively impact the all-important feedback loop that a CI/CD workflow provides. To address this many teams add a toggle removal task to their backlog when they introduce a new Release Toggle and have some kind of “expiration date” for existing toggles that aren’t being actively used.