How Azure App Configuration helps developers roll out new features | Azure Friday

Jimmy Campbell is back to show Scott Hanselman how to use App Configuration for feature management. Traditionally, shipping a new application feature requires a complete redeployment of the application itself, and testing a feature often requires multiple deployments of the application. Now you can use feature flags in App Configuration to grant early access to new app functionality in production.
00:00 - Introduction
00:24 - Episode start
03:47 - Demo: Simple feature flags
06:56 - Exploring the code
12:26 - Demo: Conditional processing with feature filters
19:35 - Episode wrap-up
◉ App Configuration - aka.ms/azfr/636/01
◉ Quickstart: Add feature flags to an ASP.NET Core app - aka.ms/azfr/636/02
◉ Getting started with Azure App Configuration - aka.ms/azfr/636/03
◉ microsoft / FeatureManagement-Dotnet on GitHub - aka.ms/azfr/636/04
◉ Feature management overview - aka.ms/azfr/636/05
◉ Create a free account (Azure) - aka.ms/azfr/636/free
#Microsoft #Azure

[@saikiranpasam3113]

Great session

[@chrisboot8535]

Great video. Definately going to be trying to get authorisation to use this in a future release of our software

[@ardravyakar]

Thank you 😊

[@OvRaf]

how feature management works with azure functions? I didnt notice in startup class reference to config. service connection string

[@cloudyfying2966]

How can we use feature flags in AKS and containers ? any useful resource to look at ?

[@colinrippey1723]

This was great, I am wondering what the code looked like for determining the user name and/or group membership and how the feature was then enabled for these specific users?

[@ziptiealot]

Hello Colin,
Here is the code for the demo application: github.com/jimmyca15/NorthWindTradersFeatureRollout
Here is how the user/group is determined: github.com/jimmyca15/NorthWindTradersFeatureRollout/blob/master/NorthwindTradersBikeShop/FeatureManagement/HttpContextTargetingContextAccessor.cs
This is the only piece that lives in the application, the rest of the implementation (determining if user is in the configured percentage) is in the open source Microsoft.FeatureManagement package: github.com/microsoft/FeatureManagement-Dotnet

[@colinrippey1723]

Jimmy thank you.

[@greg5143]

One thing he didn't touch on for the auto refresh of Azure App Config is that I thought you needed to specify a sentinel value that when changed triggers the refresh. Or is that not required anymore?

[@ziptiealot]

The "UseFeatureFlags" method in "Program.cs" sets up Azure App Configuration to check for changes in feature flags. This combined with the "UseAzureAppConfiguration" method in "Startup.cs" completes the refresh functionality.
(Edit)
If the application requires settings other than feature flags to be refreshed, then the sentinel value pattern that you mentioned still needs to be used. What I mentioned above is only for feature flags.

[@greg5143]

@@ziptiealot Ah interesting. Thanks for the response. I'm curious why app values need the sentinel to refresh, but feature flags don't.

[@2006zachery]

What about other language app? like Vue?

[@VolodymyrBilyachat]

Does libarry include management sdk? So Can I modify those feature toggles from my code if i need to ?

[@ziptiealot]

The Microsoft.FeatureManagement library does not include what you're referring to. To update feature flags, which are settings in Azure App Configuration, the App Configuration SDK would have to be used: github.com/Azure/azure-sdk-for-net/tree/master/sdk/appconfiguration/Azure.Data.AppConfiguration

[@VolodymyrBilyachat]

@@ziptiealot and targeting can be updated via that sdk too?

[@ziptiealot]

​@@VolodymyrBilyachat Yes it can. One thing to take note of is that feature flags are just configuration settings with a specific schema. The schema for feature flags can be found here: github.com/Azure/AppConfiguration/blob/master/docs/FeatureManagement/FeatureFlag.v1.0.0.schema.json

this config service is pretty nice BUT what I think is bad is the example presented... the decision between beta / preview and prod version should have come on a reverse proxy level / load balancer level and not in app code. It will make the code more complicated. I can see other use cases for this service though

[@ziptiealot]

Hello Filip, thanks for bringing up a good discussion. There are many cases where functionality can and should be offloaded to a load balancer. It is arguable that feature management falls into this category. However, there are certain criteria for enabling a feature that certain developers/systems may not have access to within a load balancer. A model where this data is consumed in the application is needed for this. Certainly though, implementing feature management in a load balancer would have many benefits.

Jimmy Campbell I don’t have any argument against enabling certain features by a configuration switch. In fact it can be useful. My comment was mostly related to the name of that particular switch “beta” as it suggest that we should have a whole new version of the app enabled by a switch which might mean that we should hold 2 versions of an application ready in the same build. That might be problematic from the complexity perspective (especially going from beta to prod to the next beta would require some code changes and strict discipline related to release and versioning) and maybe in that case having 2 builds deployed would be easier. The example presented was very simple as the “beta” meant only one change related to the view selection. This however may not scale in regard to the number of changes.
But as said the feature in itself is nice, my comment was only related to the example.

[@artisticcheese]

Is this architecture is in fact based on pull config data on every hit to default page? This seems terrible ineffective if application has to query remote configuration store on every hit

[@ziptiealot]

The feature flags are pulled into the application through the Microsoft.Azure.AppConfiguration.AspNetCore NuGet package. This package does query the remote configuration store to see if there were any changes, but it does not happen on every single request. The library has a configurable cache period, and only when the cache period has expired will the app check to see if there are any changes.

[@artisticcheese]

@@ziptiealot That's good but based on this exchange th-cam.com/video/Bzm6BfDSpuk/w-d-xo.html it was stated that it's done on every hit to a page

[@ziptiealot]

@@artisticcheese Good point. I was referring to Scott's point about the request being the trigger to see if the configuration was stale. I should have clarified that it doesn't happen on every request since he said that in his statement.

[@TheMajgotra]

This solves only part of the problem.How to support feature that includes on-prem app changes?how to support feature that include database changes?

[@ziptiealot]

This demo discusses how Azure App Configuration can be used to supply feature flags to an app and can be consumed via the Microsoft.FeatureManagement NuGet package. It is also possible to use a different source for feature flags. This is possible by implementing the IFeatureDefinitionProvider interface. Link: github.com/microsoft/FeatureManagement-Dotnet#custom-feature-providers

[@rabirini]

print("Its Just awesome.")

[@joaquingomezz6232]

Porque borraste el five nights at freddy gratis porque ponlo de nuevo porfaaaaaaaaa escrive en español o pon yes o nou