You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -954,7 +955,7 @@ The `Allocation` setting of a feature flag has the following properties:
954
955
|`DefaultWhenDisabled`| Specifies which variant should be used when a variant is requested while the feature is considered disabled. |
955
956
|`DefaultWhenEnabled`| Specifies which variant should be used when a variant is requested while the feature is considered enabled and no other variant was assigned to the user. |
956
957
|`User`| Specifies a variant and a list of users to whom that variant should be assigned. |
957
-
|`Group`| Specifies a variant and a list of groups the current user has to be in for that variant to be assigned. |
958
+
|`Group`| Specifies a variant and a list of groups. The variant will be assigned if the user is in at least one of the groups. |
958
959
|`Percentile`| Specifies a variant and a percentage range the user's calculated percentage has to fit into for that variant to be assigned. |
959
960
|`Seed`| The value which percentage calculations for `Percentile` are based on. The percentage calculation for a specific user will be the same across all features if the same `Seed` value is used. If no `Seed` is specified, then a default seed is created based on the feature name. |
960
961
@@ -964,7 +965,9 @@ If the feature is enabled, the feature manager will check the `User`, `Group`, a
964
965
965
966
Allocation logic is similar to the [Microsoft.Targeting](./README.md#MicrosoftTargeting) feature filter, but there are some parameters that are present in targeting that aren't in allocation, and vice versa. The outcomes of targeting and allocation are not related.
966
967
967
-
#### Overriding Enabled State with a Variant
968
+
**Note:** To allow allocating feature variants, you need to register `ITargetingContextAccessor`. This can be done by calling the `WithTargeting<T>` method.
969
+
970
+
### Overriding Enabled State with a Variant
968
971
969
972
You can use variants to override the enabled state of a feature flag. This gives variants an opportunity to extend the evaluation of a feature flag. If a caller is checking whether a flag that has variants is enabled, the feature manager will check if the variant assigned to the current user is set up to override the result. This is done using the optional variant property `StatusOverride`. By default, this property is set to `None`, which means the variant doesn't affect whether the flag is considered enabled or disabled. Setting `StatusOverride` to `Enabled` allows the variant, when chosen, to override a flag to be enabled. Setting `StatusOverride` to `Disabled` provides the opposite functionality, therefore disabling the flag when the variant is chosen. A feature with a `Status` of `Disabled` cannot be overridden.
970
973
@@ -1000,6 +1003,56 @@ If you are using a feature flag with binary variants, the `StatusOverride` prope
1000
1003
1001
1004
In the above example, the feature is enabled by the `AlwaysOn` filter. If the current user is in the calculated percentile range of 10 to 20, then the `On` variant is returned. Otherwise, the `Off` variant is returned and because `StatusOverride` is equal to `Disabled`, the feature will now be considered disabled.
1002
1005
1006
+
### Variants in Dependency Injection
1007
+
1008
+
Variant feature flags can be used in conjunction with dependency injection to surface different implementations of a service for different users. This is accomplished through the use of the `IVariantServiceProvider<TService>` interface.
In the snippet above, the `IVariantServiceProvider<IAlgorithm>` will retrieve an implementation of `IAlgorithm` from the dependency injection container. The chosen implementation is dependent upon:
1018
+
* The feature flag that the `IAlgorithm` service was registered with.
1019
+
* The allocated variant for that feature.
1020
+
1021
+
The `IVariantServiceProvider<T>` is made available to the application by calling `IFeatureManagementBuilder.WithVariantService<T>(string featureName)`. See below for an example.
The call above makes `IVariantServiceProvider<IAlgorithm>` available in the service collection. Implementation(s) of `IAlgorithm` must be added separately via an add method such as `services.AddSingleton<IAlgorithm, SomeImplementation>()`. The implementation of `IAlgorithm` that the `IVariantServiceProvider` uses depends on the `ForecastAlgorithm` variant feature flag. If no implementation of `IAlgorithm` is added to the service collection, then the `IVariantServiceProvider<IAlgorithm>.GetServiceAsync()` will return a task with a *null* result.
1029
+
1030
+
```javascript
1031
+
{
1032
+
// The example variant feature flag
1033
+
"ForecastAlgorithm": {
1034
+
"Variants": [
1035
+
{
1036
+
"Name":"AlgorithmBeta"
1037
+
},
1038
+
...
1039
+
]
1040
+
}
1041
+
}
1042
+
```
1043
+
1044
+
#### Variant Service Alias Attribute
1045
+
1046
+
```C#
1047
+
[VariantServiceAlias("Beta")]
1048
+
publicclassAlgorithmBeta : IAlgorithm
1049
+
{
1050
+
...
1051
+
}
1052
+
```
1053
+
1054
+
The variant service provider will use the type names of implementations to match the allocated variant. If a variant service is decorated with the `VariantServiceAliasAttribute`, the name declared in this attribute should be used in configuration to reference this variant service.
1055
+
1003
1056
## Telemetry
1004
1057
1005
1058
When a feature flag change is deployed, it is often important to analyze its effect on an application. For example, here are a few questions that may arise:
0 commit comments