Releasing Features the Smart Way in .NET

Hello, everybody, I'm Nick, and in this video, I will show you how you can use Feature Flags to release your new features in .NET. Feature Flags are part of feature management and Microsoft has created a Nuget package to make the process easier.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[JeffryGonzalezHt]

Good stuff - feature toggles are required for successful CI, for sure. We use percentage flags often for A/B testing, or slowly rolling out a new version of something we are monitoring, or "canary" features for a subset of users. So you'd have two routes for /weatherforecasts - one with the new version, one with the old, one would be disabled if the flag is true, the other disabled, etc. You can do cool stuff like that when you are decomposing a monolith using a strangler fig pattern for example. What I wish was easier, and you hinted at it here, was the ability to change the container for the services based on feature flags. Since you can't change the services collection after the app is built, you have to do corny stuff like the common service locator thing you showed.

[rsamuseu]

We use feature flags on our project. FF is great when you need to enable or disable functionality depending on requirements. For example, multicountry applications where for some of the country feature could be enabled and for others be disabled. Also, disabling some features helps to test functionality on the prod without any damage because it will be hidden from the user

[YungDeiza]

Feature flags are great for products that can be deployed for multiple clients who may want some features or enabled or disabled based on their requirements

[baranacikgoz]

I was tought wait a sec, that could be done with simply adding a flag by yourself in appsettings, not via package. Then things got advanced ;) Great video

[kasasatimothy]

Thank you so much, have been doing this manually... Will start using this library

[PierreH]

Thanks! That is a great way to do complex A-B testing! Thanks again for sharing!

[rogeriobarretto]

Amazing stuff, wasn't aware of a such nice package until recently. Great video!

[mahmoudalaskalany]

That is a very good explanation as usual my mentor, i think i will use a lot of your info in my next tech post ❤🎉

[zebcode]

Great stuff, I decided to opt to use an enum to define the constants rather than const strings for the feature names. Though it's still going to be suspectable to breakages should the name be refactored. Meh, it's on me in this project. It's something small I'm making for myself.

[julienraillard]

Really interesting feature as always ! :)
Would you like to show us the "AddSessionManager" too ? :D

[inzyster]

I wasn't aware of this, I'll make sure everyone in my team is :)

[sa-es-ir]

Feature flags is very useful if you are using trunk base development (TBD)

[AnySL]

We use features/toggles concepts to customize ui for different clients as well as enable all for premium clients

[ChallusMercer]

Thank you for insights on this topic. Can you maybe elaborate further on this by explaining what is the best way of releasing some features for specific users. Maybe you could make a video on this topic.

[ivankiselychnyk]

cool video, I used this package on previous project

[elpe]

For me, you're the Feature Manager ! :D

[RussianBananan]

Nice overview, thanks! Is there any strategy on how to coordinate feature flags being enabled/disabled with frontend? I guess both BE and FE should manage feature flags at the same time in order not to be in the situation of enabled BE feature, which is not visible from FE, or, what is worse, disabled BE feature, getting called from FE.

[CursedFire]

Hey Nick thanks for the video.

Actually, I have the thought to use this feature more in my development team, considering another branching strategy. Currently, we use GitFlow, but the team has grown so much that our Staging environment has become a bottleneck.

Therefore, I have also considered that using Feature Management at the version level might help manage a more transparent branching strategy between staging and production environments. For example, using the Trunk-Based Development (TBD) strategy, working with a single version Feature Flag and i would call it Version Flag, and if you want to work at a lower level, i will add a new level to use a feature flag.

I see great advantages with this approach, as it would help our Staging and Production environments focus on a specific version... So, it is also understandable that the team must be disciplined in keeping the code updated by cleaning up the legacy code.

What you do think over this tought?

[fronix]

I use percentage features when I want to troll QA-testers. It's a lot of fun :)

[LindenMikus]

perhaps this could be a good way to release a new api version for endpoints. for the percentage setting, maybe a nice use case would be for a game of chance