In this post, I introduced the concept, and Microsoft’s implementation, of Feature Flags. In fact, there’s a lot more to both than I covered in this initial post. In this post, I want to cover how you could use this to turn a particular feature on for a single user, or a group of users. You can even specify groups for those users, and allow all, or some of those users to see the feature.
It’s worth noting that, at the time of writing, this functionality is currently only in preview; you’ll need the following NuGet package (or later) for it to work:
[code lang=“html”]
Before we get into how to use this, let's have a quick look at the [source](https://github.com/microsoft/FeatureManagement-Dotnet). The interesting method is **EvaluateAsync**. Essentially this method returns a boolean indicating whether or not the feature is available; you could simply return **true** and the feature would always be enabled; but let's see an abridged version of this method:
``` csharp
public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context, ITargetingContext targetingContext)
{
. . .
//
// Check if the user is being targeted directly
if (targetingContext.UserId != null &&
settings.Audience.Users != null &&
settings.Audience.Users.Any(user => targetingContext.UserId.Equals(user, ComparisonType)))
{
return Task.FromResult(true);
}
//
// Check if the user is in a group that is being targeted
if (targetingContext.Groups != null &&
settings.Audience.Groups != null)
{
foreach (string group in targetingContext.Groups)
{
GroupRollout groupRollout = settings.Audience.Groups.FirstOrDefault(g => g.Name.Equals(group, ComparisonType));
if (groupRollout != null)
{
string audienceContextId = $"{targetingContext.UserId}\\n{context.FeatureName}\\n{group}";
if (IsTargeted(audienceContextId, groupRollout.RolloutPercentage))
{
return Task.FromResult(true);
}
}
}
}
//
// Check if the user is being targeted by a default rollout percentage
string defaultContextId = $"{targetingContext.UserId}\\n{context.FeatureName}";
return Task.FromResult(IsTargeted(defaultContextId, settings.Audience.DefaultRolloutPercentage));
}
So, the process is that it looks for specific users and, if it finds them, they can see the feature; if it cannot find them then it looks through the groups (we’ll come back to IsTargeted later), and finally reverts to the DefaultRolloutPercentage - again, we’ll look into what that is later on.
Let’s start with a single user
If you have a look at the previous post, you’ll see that the Feature Management system is being added using the following syntax:
services.AddFeatureManagement();
In order to add one of the pre-defined filters, we’ll need to add to this like so:
services.AddFeatureManagement()
.AddFeatureFilter<TargetingFilter>();
You’ll also need the following class importing:
using Microsoft.FeatureManagement.FeatureFilters;
If you run this now, you’ll get the following error:
System.InvalidOperationException: ‘Unable to resolve service for type ‘Microsoft.FeatureManagement.FeatureFilters.ITargetingContextAccessor’ while attempting to activate ‘Microsoft.FeatureManagement.FeatureFilters.TargetingFilter’.’
The reason being that you need to identify a ITargetingContextAccessor. What exactly this looks like is up to the implementer, but you’ll find an example implementation here.
We’ll come back to this shortly in the groups section.
Let’s now have a look at what our appsettings.json might look like:
"FeatureManagement": {
"MyFeature": {
"EnabledFor": [
{
"Name": "Targeting",
"Parameters": {
"Audience": {
"Users": [
"[email protected]"
]
}
}
}
]
}
If we have a look at the default HttpContextTargetingContextAccessor (see the link above for the ITargetingContextAccessor), we’ll see that the UserId is being set there:
TargetingContext targetingContext = new TargetingContext
{
UserId = user.Identity.Name,
Groups = groups
};
This isn’t particularly controversial - at least the User Id part isn’t; however, it doesn’t have to be this; for example, you could get the family_name claim, and return that - and then you could target your feature to anyone named Smith. It’s a bit of a silly example, but the point is that you can customise how this works (in fact, you can write a completely custom filter, which I’ll probably cover in a later post).
This part of the Feature Management is not to be underestimated: you could release a feature, in live, to only one or two Beta Testers. However, it is quite specific; that’s where Groups come in.
Groups
Groups are slightly more interesting. You can specify which groups are in and out using the following configuration:
"FeatureManagement": {
"MyFeature": {
"EnabledFor": [
{
"Name": "Targeting",
"Parameters": {
"Audience": {
"Users": [],
"Groups": [
{
"Name": "Group1",
"RolloutPercentage": 80
},
{
"Name": "Group2",
"RolloutPercentage": 40
}
],
"DefaultRolloutPercentage": 20
}
}
}
]
},
The RolloutPercentage here indicates what proportion of the group that you wish to be included.
Do you remember the IsTargeted method from earlier? This is what it looks like:
private bool IsTargeted(string contextId, double percentage)
{
byte[] hash;
using (HashAlgorithm hashAlgorithm = SHA256.Create())
{
hash = hashAlgorithm.ComputeHash(Encoding.UTF8.GetBytes(contextId));
}
//
// Use first 4 bytes for percentage calculation
// Cryptographic hashing algorithms ensure adequate entropy across hash
uint contextMarker = BitConverter.ToUInt32(hash, 0);
double contextPercentage = (contextMarker / (double)uint.MaxValue) \* 100;
return contextPercentage < percentage;
}
To an extent, this is a random selection, but it uses the User ID and feature name to calculate the hash for that selection (that’s what gets passed into contextId), meaning that the same user will see the same thing each time. You may also find when playing with this that for small numbers, it doesn’t really match the expectation; for example, at 40%, you would expect around two out of five users to see the feature, but when I ran my test, all the five users could see the feature. Larger numbers work better, although the fact that this is tied to the User Id makes it a little tricky to test (you can’t simply launch the site and press Ctrl-F5 until it switches over).
Again, it’s worth pointing out that what a group is, is determined by you (or at least the creator of the HttpContextTargetingContextAccessor). This means that you can base this on a claim, on the first letter of the username, the time of day, anything you like. I haven’t tried it, but I suspect you could put a DB query in here, too. That’s probably not the best idea, because it gets called a lot, but I believe it’s possible.
Default Rollout Percentage
Here we have a catch-all - if the user is not in the group, and not identified as a user, this will allow you to expose your feature to a percentage of the user base. Again, this isn’t something you can easily check by refreshing your page, as it’s based on a hash of the user, group, and feature name. In fact, this won’t work very well at all if you’re not using any kind of identiy.