Our first goal is decoupling deployment and exposure. We want to be able to control when a feature is available to users without having to time when the code is committed. This allows engineering the freedom to implement the feature based on our needs while also allowing control for the business on when a feature is announced. Next we want to be able to change the setting at any scope from globally to particular scale units to accounts to individual users. This granularity gives us a great deal of flexibility. We can deploy a feature and then expose it to select users and accounts. That allows us to get feedback early, which includes not only what users tell us but also how the feature is used based on aggregated telemetry. Additionally, we want to be able to react quickly if a feature causes issues and be able to turn it off quickly.<\/p>\n
To make all of this work well, we need to be able to change a feature flag\u2019s state without re-deploying any of our services. We need each service to react automatically to the change to minimize the propagation delay.<\/p>\n
As a result, we have the following goals.<\/p>\n
- \n
- Decouple deployment and exposure \n
- Control down to an individual user \n
- Get feedback early \n
- Turn off quickly \n
- Change without redeployment <\/li>\n<\/ul>\n
Feature flags<\/strong><\/p>\n
Feature flags, sometimes called feature switches, allow us to achieve our goals. At the core, a feature flag is nothing more than an input to an if statement in the code: if the flag is enabled, execute a new code path, and else if not, execute the existing code path.<\/p>\n
Let\u2019s look at an actual example. In this case I want to control whether a new feature to revert a pull request is available to the user. I\u2019ve highlighted the Revert button in the screen shot.<\/p>\n
![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/39\/2019\/03\/image_thumb646.png\" "\\"image\\"")
<\/a><\/p>\nFirst we need to define the feature flag. We do that by defining it in an XML file. Each service in VSTS has its own set of flags. Here\u2019s part of the actual file that defines the feature flag for this button with the name of the feature flag highlighted.<\/p>\n
\n
<?<\/span>xml <\/span>version<\/span>=<\/span>\"<\/span>1.0<\/span>\" <\/span>encoding<\/span>=<\/span>\"<\/span>utf-8<\/span>\"<\/span>?>\n<!-- <\/span>In this group we should register TFS specific features and sets their states. <\/span>-->\n<<\/span>ServicingStepGroup <\/span>name<\/span>=<\/span>\"<\/span>TfsFeatureAvailability<\/span>\" <\/span>\u2026<\/span>=<\/span>\"\" <\/span>>\n <<\/span>Steps<\/span>>\n <!-- <\/span>Feature Availability <\/span>-->\n <<\/span>ServicingStep <\/span>name<\/span>=<\/span>\"<\/span>Register features<\/span>\" <\/span>stepPerformer<\/span>=<\/span>\"<\/span>FeatureAvailability<\/span>\" <\/span>\u2026<\/span>=<\/span>\"\" <\/span>>\n <<\/span>StepData<\/span>>\n <!--<\/span>specifying owner to allow implicit removal of features <\/span>-->\n <<\/span>Features <\/span>owner<\/span>=<\/span>\"<\/span>TFS<\/span>\"<\/span>>\n <!-- <\/span>Begin TFVC\/Git <\/span>-->\n <<\/span>Feature <\/span>name<\/span>=<\/span>\"<\/span>SourceControl.Revert<\/font><\/span>\" <\/span>description<\/span>=<\/span>\"<\/span>Source control revert features<\/span>\" <\/span>\/><\/span><\/pre>\n<\/blockquote>\nWhen we deploy the service that defined this feature flag, the deployment engine will create the feature flag in the database.<\/p>\n
Using the feature flag in code is simple. Here\u2019s the Typescript code that is used to create the button. I\u2019ve combined contents from two files. The export is from a file that defines constants. The rest is from the code to create the button on the page. I\u2019ve highlighted the flag and the button creation. In this case, there was no prior code, so if the flag is off, nothing gets added to the page.<\/p>\n
\n
export module <\/span>FeatureAvailabilityFlags {\n <\/span>export var <\/span>SourceControlRevert = <\/span>\"SourceControl.Revert<\/font>\"<\/span>;\n}\n\n<\/span>import <\/span>FeatureAvailability = <\/span>require<\/span>(<\/span>\"VSS\/FeatureAvailability\/Services\"<\/span>);\n<\/span>private <\/span>_addRevertButton(): <\/span>void <\/span>{\n <\/span>if<\/span>(FeatureAvailability.isFeatureEnabled(FeatureAvailabilityFlags.SourceControlRevert<\/font>)) {\n <\/span>this<\/span>._calloutButtons.unshift(\n <button onClick={ () => Dialogs.revertPullRequest(\n <\/span>this<\/span>.props.repositoryContext,\n <\/span>this<\/span>.props.pullRequest.pullRequestContract(),\n <\/span>this<\/span>.props.pullRequest.branchStatusContract().sourceBranchStatus,\n <\/span>this<\/span>.props.pullRequest.branchStatusContract().targetBranchStatus) }\n >{ VCResources.PullRequest_Revert_Button<\/font> } < <\/span>\/button>\n <\/span>);\n }\n }<\/span><\/pre>\n<\/blockquote>\nIn addition to the web UI, the code for the MVC controller is also protected with a feature flag. I\u2019m omitting the definition of the constant and some of the code for brevity, but as you can see the only mention of the feature flag is in the attribute on the controller, making it really easy to control the feature with a flag.<\/p>\n
\n
namespace <\/span>Microsoft.TeamFoundation.SourceControl.WebServer\n{\n [FeatureEnabled(FeatureAvailabilityFlags.SourceControlRevert)]<\/font>\n <\/span>public class <\/span>GitRevertsController <\/span>: GitApiController\n {\n [HttpPost]\n <\/span>public <\/span>HttpResponseMessage CreateRevert(\n [FromBody] WebApi.GitAsyncRefOperationParameters revertToCreate,\n [ClientParameterType(<\/span>typeof<\/span>(Guid), <\/span>true<\/span>)] <\/span>string <\/span>repositoryId,\n [ClientIgnore] <\/span>string <\/span>projectId = <\/span>null<\/span>)\n {\n }\n\n [HttpGet]\n <\/span>public <\/span>GitRevert GetRevertForRefName(\n [FromUri] <\/span>string <\/span>refName,\n [ClientParameterType(<\/span>typeof<\/span>(Guid), <\/span>true<\/span>)] <\/span>string <\/span>repositoryId,\n [ClientIgnore] <\/span>string <\/span>projectId = <\/span>null<\/span>)\n {\n }\n\n [HttpGet]\n <\/span>public <\/span>GitRevert GetRevert(\n <\/span>int <\/span>revertId,\n [ClientParameterType(<\/span>typeof<\/span>(Guid), <\/span>true<\/span>)] <\/span>string <\/span>repositoryId,\n [ClientIgnore] <\/span>string <\/span>projectId = <\/span>null<\/span>)\n {\n }\n }\n}<\/span><\/pre>\n<\/blockquote>\nThe FeatureEnabled attribute checks to see if the specified feature flag is enabled and throws an exception if not.<\/p>\n
public class <\/span>FeatureEnabledAttribute <\/span>: AuthorizationFilterAttribute\n {\n <\/span>public <\/span>FeatureEnabledAttribute(<\/span>string <\/span>featureFlag)\n {\n <\/span>this<\/span>.FeatureFlag = featureFlag;\n }\n\n <\/span>public string <\/span>FeatureFlag { <\/span>get<\/span>; <\/span>private set<\/span>; }\n\n <\/span>public override void <\/span>OnAuthorization(HttpActionContext actionContext)\n {\n <\/span>base<\/span>.OnAuthorization(actionContext);\n TfsApiController tfsController = actionContext.ControllerContext.Controller <\/span>as <\/span>TfsApiController;\n <\/span>if <\/span>(tfsController != <\/span>null<\/span>)\n {\n <\/span>if <\/span>(!tfsController.TfsRequestContext.IsFeatureEnabled(<\/span>this<\/span>.FeatureFlag))\n {\n <\/span>throw new <\/span>FeatureDisabledException(FrameworkResources.FeatureDisabledError());\n }\n }\n }\n }<\/span><\/pre>\nOther than some similar code for a menu entry for revert, the feature flag has now been added for the new feature.<\/p>\n
Controlling feature flags<\/strong><\/p>\n
We have both PowerShell commands and a web UI to turn the feature flags off and on for different scopes.<\/p>\n
Our PowerShell commands are what you would expect: Get-FeatureFlag and Set-FeatureFlag. Here are some examples of what they can do.<\/p>\n
\n\n
\n Getting all flags and their states globally<\/td>\n Get-FeatureFlag<\/font> <\/td>\n<\/tr>\n \n Getting all flags and states for a single account<\/td>\n Get-FeatureFlag -Host account<\/font> <\/td>\n<\/tr>\n \n Getting information for one flag globally<\/td>\n Get-FeatureFlag -Name feature_name<\/font> <\/td>\n<\/tr>\n \n Getting information for one flag in account<\/td>\n Get-FeatureFlag -Name feature_name \u2013Host account<\/font> <\/td>\n<\/tr>\n \n Setting a feature flag globally<\/td>\n Set-FeatureFlag -Name feature_name -State {Off|On|Undefined} <\/font><\/td>\n<\/tr>\n \n Setting a feature flag for a single account <\/td>\n Set-FeatureFlag -Name feature_name -State {Off|On|Undefined} -Host account<\/font> <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n <\/p>\n
We also have internal site that provides an interactive way to do the same operations. In this example, you can see that I have the feature flag for the revert feature on for one of my personal accounts and off for the other. This is a great way to be able to control the flags for accounts on demand, such as when we allowed customers to request SSH<\/a> before it became broadly available.<\/p>\n
![\"image\"](\"https:\/\/devblogs.microsoft.com\/wp-content\/uploads\/sites\/39\/2019\/03\/image778.png\" "\\"image\\"")
<\/a><\/p>\n