A toggle is a switch that has two positions, on or off. Toggle switches are used for many purposes, including in e-commerce websites to hide sent messages and in video chat applications to switch between screen sharing and single-user mode.
Toggles are often used in software development to support agile approaches to release management. They allow teams to develop and test new features on code branches without the need to push those changes back into trunk (where they would normally be integrated). Once a feature is ready for release it can then be hidden behind a toggle so it can be made available to a limited cohort of users. Once the feature has been fully tested and verified it can be rolled out to all users. This process is sometimes known as a Champagne Brunch Release or a Canary Release.
When a toggle is flipped on it can have significant impact on the running of a software system. It may cause additional code paths to be triggered or the application to behave in different ways. It is generally best to limit the scope of a feature toggle and ensure it covers only a small part of a codebase. Otherwise it can be very difficult to manage and debug if there are unexpected side-effects or bugs caused by the feature.
Depending on the size of a production software system it is often preferable to use static configuration for feature toggles rather than more dynamic methods. This is because a toggle that is hardcoded into code will only be re-configured by rolling out a new release version and deploying the changed code.
Some developers choose to hardcode their toggles using preprocessor macros like #ifdef to make them more stable and robust. While this is a good option for very simple toggles it becomes impractical as the scale of a deployment grows. For this reason, it is generally advisable to move feature flag configuration out of source control and into some sort of centralized store – usually an existing application DB. In addition to reducing complexity this approach also makes it easier to maintain consistency across a fleet of servers.
Once a toggle has been rolled out to production it is important to test both the configured state of the toggle (i.e. if it is On or Off) and the fallback state which the release will apply if the toggle is flipped off. Some teams go so far as to also test the release with all toggles flipped Off, to help avoid any surprise regressions in future releases.
It is very tempting to add large swathes of code into the control of a toggle switch. However, this can lead to complex series of toggles that are difficult for the team to manage and for users to understand. It is also worth ensuring that any toggles which are no longer required should be removed from the application as soon as possible. This can be done either by adding maintenance tasks to the team’s backlog or by building a process into your release management platform.
