A toggle is a piece of hardware or software that has two positions, one being on and the other being off. For example, you can toggle between video chatting with one person at a time or switching between stream and map views when navigating a website. The word toggle can also be used as a verb meaning to switch back and forth between these two positions, such as when someone switches between their work email and personal email.
The idea behind Feature Flags and Toggles is that developers can create different configurations for a given service instance, allowing the same codebase to be run on both a production and development environment. The difference between these configurations is controlled by the toggles, which are set at runtime by the feature flags config. This allows teams to test, develop and deploy features at a much faster pace than traditional releases that require the application to be restarted after each change to the source codebase.
Depending on how your team is using feature flags it may be necessary to have a centralized place to manage toggle configuration. This could be a dedicated config DB, an existing app DB or some sort of admin UI that allows system operators, testers and product managers to view and modify the configuration of a particular service instance. Many teams opt to use a combination of these methods, storing the Toggle Configuration in both static files and a centralized location such as an existing application DB.
When testing a release it’s important to understand the intended behavior of each toggle. Toggle labels should always be clear, concise and specific in order to avoid any confusion. Toggle switches should utilize visual cues like movement and color to signal their state. Ideally the visual representation of a toggle should have high contrast in order to be easily visible. It’s also wise to keep in mind the societal and cultural implications of color usage, for example, red for an off position might not make sense for a population that associates it with traffic signals.
Savvy teams view their Feature Toggle inventory as having a carrying cost and attempt to keep it low by being proactive in removing old, deprecated or superseded toggles from the codebase. This can be done by simply adding a toggle removal task to the team’s backlog as each new Release Toggle is added or some teams go as far as to put “expiration dates” on their toggles, failing a test (or even refusing to start the application) once a toggle has expired.
