The third form of progressive deployment can be achieved using feature flags, also called feature toggles. Where canary deployments and ring-based deployments rely on slowly exposing new binaries to an increasing number of users, feature flags are used to slowly expose new features to an increasing number of users. This can be achieved even if they are all sending requests to the same server. Feature flags are used to decouple deploying a new version of the application binaries from releasing new features by enabling or disabling specific features at runtime.
The best example of a feature flag is showing or hiding a button that gives users access to a new feature. Application settings, a database, or an external service are used to keep track of which feature has been enabled for which user. Depending on that setting, the feature is shown or hidden. Examples of such external services include LaunchDarkly, Split.IO, and Prefab.cloud.
Other feature flags might toggle bug fixes or performance improvements on or off. This can help to gradually expose these to ensure there are no issues. When using feature toggles for these kinds of changes deeper in a codebase, introducing feature toggles also comes with a cost, and a process for this should be in place. This process should not only describe adding feature toggles, but also how to remove them as soon as possible. An example of such a process can be as follows.
A new feature flag is introduced by a developer as soon as the business needs to release the feature independently of the deployments that were made by the development team, or for a change that the development team qualifies as high risk and wants to be able to pull back at any time without redeploying it. Introducing a feature flag means a new database entry or a declaration of a new setting is applied in the application settings.
After introducing the feature toggle, the new feature or change is developed and tested. This means that there are one or more if statements in the codebase that execute different code paths, depending on the state of the feature flag. At this point, the application must maintain two code execution paths until they remove the feature flag again. It is good practice to separate these two code paths as much as possible using existing engineering practices, such as dependency injection.
While the code is continuously being shipped to users, the feature is not enabled for anyone. Only when the development team is fully satisfied with the change or the product owner feels the time is right for releasing a new feature is the feature flag turned on.
It is important not to stop here. After turning the feature flag on, it should actively be determined whether the feature or change is working properly. And if it is, the feature flag should be removed as soon as possible. This way, the time the two code paths need to be maintained for is as short as possible.
Also, note that besides maintaining an increased number of execution paths, there is now a larger number of paths to test. The impact of this consequence quickly grows if dependencies or exclusions between feature flags are introduced. Feature flags that can only be turned on or off, depending on the state of another feature flag, can be costly, and it is recommended to avoid this.
If implemented properly and removed as soon as possible, the added cost of feature flags is often worth it. As with every engineering practice, start small and evaluate what works in the given context, before adapting the practice at scale.