Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
I think this is an important topic that is easy to ... well, just not know about!
Thanks for adding this topic to your collection of posts!
Launching new features "darkly" (code is in the app, but a feature flag has it turned off) will allow teams to continue to keep code merging into master, deploying, running tests on new code without requiring it to be fully completed.
One thing I would add is (and I realize you aren't recommending this practice - you just wrote some example code) is to move the Feature Flag logic out of a static global class.
Those static helper classes aren't testable and are often directly tied to volatile dependencies (ex: database, file system, app-settings.json/AppSettings.config).
Instead either supply a feature service behind an interface:
publicinterfaceIFeatureService{boolIsFeatureEnabled(stringfeatureName);}// or ...publicinterfaceIFeatureService{boolIsFeatureEnabled<TContext>(TContextfeatureContext);}
Where you can abstract away logic to determine if the feature is enabled by checking an API, database, or environment configuration.
This approach is helpful when features need to be dynamic based on the execution context (ex: not the same for every user).
The other option is to create very specific feature 'configuration' classes that are populated in your composition root when using Inversion of Control and a Dependency Injection container.
I had not worked with Microsoft.FeatureManagement before. My go-to with .NET has been FeatureToggle despite some of the odd syntax, because it makes spelling mistakes in configurations a non-issue by erroring early and by giving you strongly-typed solutions. I'll have to look into feature management more.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
The error-ing early part is something I always lean towards when possible.
IoC containers like SimpleInjector verify your container by building everything in it 1 time at startup.
If you include your Feature configuration types in your container then the verification step will throw an exception if values can't be found in app settings or the database (assuming your classes guard against invalid parameters).
I haven't used FeatureToggle - I'll have to check it out.
Lead Product Evangelist @Kentico, Founding partner @craftbrewingbiz. love to learn / teach web dev & software engineering, collecting vinyl records, mowing my lawn, craft 🍺
I think this is an important topic that is easy to ... well, just not know about!
Thanks for adding this topic to your collection of posts!
Launching new features "darkly" (code is in the app, but a feature flag has it turned off) will allow teams to continue to keep code merging into master, deploying, running tests on new code without requiring it to be fully completed.
One thing I would add is (and I realize you aren't recommending this practice - you just wrote some example code) is to move the Feature Flag logic out of a
static
global class.Those
static
helper classes aren't testable and are often directly tied to volatile dependencies (ex: database, file system,app-settings.json
/AppSettings.config
).Instead either supply a feature service behind an interface:
Where you can abstract away logic to determine if the feature is enabled by checking an API, database, or environment configuration.
This approach is helpful when features need to be dynamic based on the execution context (ex: not the same for every user).
The other option is to create very specific feature 'configuration' classes that are populated in your composition root when using Inversion of Control and a Dependency Injection container.
These can be populated per-request or as a singleton for the lifetime of the app, but they tend to not change often.
For example, the feature is off today, but we update the configuration value in the database tomorrow, and then it's on for everyone.
ASP.NET Core has feature management baked in, so the patterns are established - we just have to choose our implementation!
I had not worked with Microsoft.FeatureManagement before. My go-to with .NET has been
FeatureToggle
despite some of the odd syntax, because it makes spelling mistakes in configurations a non-issue by erroring early and by giving you strongly-typed solutions. I'll have to look into feature management more.The error-ing early part is something I always lean towards when possible.
IoC containers like
SimpleInjector
verify your container by building everything in it 1 time at startup.If you include your Feature configuration types in your container then the verification step will throw an exception if values can't be found in app settings or the database (assuming your classes guard against invalid parameters).
I haven't used
FeatureToggle
- I'll have to check it out.Take a look and let me know what you think.
Safe .NET Feature Flags with FeatureToggle
Matt Eland ・ Sep 21 ・ 4 min read
I appreciate you writing that up!