A toggle is a switch that has two positions, on and off. It’s the sort of switch you might use to switch between screens in a video chat with two friends at once. Toggle can also be used to refer to a feature in Continuous Delivery that allows you to experiment with new code, or to act as a circuit breaker in production when performance becomes unacceptable.
Savvy teams tend to treat feature toggles as inventory that comes with a carrying cost and seek to keep their inventory as low as possible. For this reason, many teams add a task to their release plan to remove any toggles that are no longer needed. Others even go as far as creating “time bombs” in their releases that will cause a test to fail (or even refuse to start the application!) if a toggle hasn’t been flipped off by the time of release.
Traditionally developers have managed toggle configuration via comments in source code. While this is fine for smaller, simpler applications it becomes cumbersome when scale increases and it can be difficult to manage consistency across deployments. For these reasons most organizations opt to move their toggle configuration into some type of centralized store, often an existing application DB.
Once a toggle has been migrated to a centralized store it can be more easily modified and deployed. In addition, many tools have built-in support for managing toggle configuration in a centralized store, making the migration process much faster and easier.
