microsoft / featurebits Goto Github PK

During evaluation, this feature bit is doing a "Contains()" to search for a string value. Since ExcludedEnvironments is a comma delimited string, it should be split and each item compared to the string.

private static bool EvaluateEnvironmentBasedFeatureState(IFeatureBitDefinition bitDef) { bool featureState; var env = Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT").ToUpperInvariant(); featureState = !bitDef.ExcludedEnvironments.ToUpperInvariant().Contains(env); return featureState; }

There is any relation with the development of the package Microsoft.FeatureManagement, nuget, github, documentation, that seems to come from the Azure team.
Both packages have related goals, they work both on netcore.
It would be better, IMHO, tohave a unified approach to feature flags.

I cloned the repo and inserted a test feature directly using SQL which incremented the identity seed. I then found your suggestion to use the 'dotnet fbit add' command. When I added the features using that command, my FeatureBitDefinitions table's identity seed no longer matched the enum values in the sample app. Since line 53 of IsEnabled in FeatureBitEvaluator is using the Id to lookup the feature it throws a KeyNotFoundException when bitDef is null.

Expected Outcome: The way features are defined in code should be decoupled from the way SQL handles identities or even from the persistence implementation itself.

Possible solutions:

• Change the Id column in FeatureBitDefinitions to be a primary key integer with a unique constraint but not an auto-incrementing identity, that way the application can supply the identity as it defines new enums.

• Change the IsEnabled implementation to look the feature up by name instead of by Id. This would require changing the SQL script to also create a unique constraint on the name column and could break existing implementations if they have duplicate names.

• Change the application architecture to make feature resolution / persistence extendable and not as tightly coupled to the database implementation.

• Enable identity insert in the FeatureBits.Console dotnet fbit command

Hello, are there any plan to support dependent features?

Schema already supports User-based feature bit, but there is no way to create one with fbit add, and there is no evaluation of user-based feature bits.

You likely lose "one data store" to control all environments, but it's an easy-to-get-started scenario.

Currently, if the feature bit doesn't exist in the database, the FeatureBitEvaluator will throw an exception instead of failing gracefully, perhaps by returning "false"

Sets it to true. Should be false.

fbit list should display feature bit definitions
By default "fbit list" shows the ID and Name of the feature bits

• Accepts a required connection string properties
• Accepts a -Long argument, which shows all feature bit fields.

the following packages are being deployed to nuget.org. dotnet-fbit.0.3.0.25.nupkg should not be deployed.

• (BUG) src\FeatureBits.Console\bin\Release\dotnet-fbit.0.3.0.25.nupkg
• src\FeatureBits.Console\bin\Release\dotnet-fbit.0.3.0.nupkg
• src\FeatureBits.Core\bin\Release\FeatureBits.Core.0.3.0.nupkg
• src\FeatureBits.Data\bin\Release\FeatureBits.Data.0.3.0.nupkg

Common elements with the .NET Core version should be abstracted out to a common .NET Standard C# project.

Example: Not in the Production environment (excluded_environments) AND between 8 am and 5 pm (time-of-day-based).

This way, it makes it simple to only allow a feature to appear in the a development environment and to be "off" in all others.

Looks like a copy-n-paste error. The argument should be the "name" of the feature bit. Namespace has nothing to do with it.

Is there a plan to upgrade these projects to .NET Core 2.1?

I've cloned the repo locally and would be interested in tackling that task, but I don't have the ability to create a branch.