You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When in Debug mode, the host used to set the Environment name to "Development ". This meant that files like appsettings.development .json would get picked up when using environment-based JSON config loading. But going into Debug mode seemed arbitrary to a lot of customers -- simply visiting the portal and causing a restart (like disabling a function) would set you in Debug mode, causing the incorrect configuration to be loaded.
With this flag, the Development environment value is never set based on the Functions Debug mode. We want this to be the default in v4
Motivation
Customers have run into hard-to-debug scenarios because of this flag. We'd rather treat the host as always in Production for the sake of consistency.
Impact
Unknown. If needed, we can see if we can gather the number of customers using the JSON configuration source, although the impact may go beyond that as the Environment string is available to any customer from within FunctionsStartup.
Compat-mode support
We could flip and add EnableDevModeInDebug, but we likely shouldn't. This can be set by an App Setting on a staging site (or slot), which makes it much more deterministic.
Alternatives
Setting the environment string in AZURE_FUNCTIONS_ENVIRONMENT as an app setting lets you explicitly control this.
Detection
Since this is a value passed to the FunctionsStartup, I don't know if we can determine how many customers are reading it. If needed, we could log an event in the getter.
Support
Hopefully this reduces support cases; there should be no explicit support education required.
When in Debug mode, the host used to set the Environment name to "Development ". This meant that files like appsettings.development .json would get picked up when using environment-based JSON config loading. But going into Debug mode seemed arbitrary to a lot of customers -- simply visiting the portal and causing a restart (like disabling a function) would set you in Debug mode, causing the incorrect configuration to be loaded.
With this flag, the Development environment value is never set based on the Functions Debug mode. We want this to be the default in v4
Motivation
Customers have run into hard-to-debug scenarios because of this flag. We'd rather treat the host as always in Production for the sake of consistency.
Impact
Unknown. If needed, we can see if we can gather the number of customers using the JSON configuration source, although the impact may go beyond that as the Environment string is available to any customer from within FunctionsStartup.
Compat-mode support
We could flip and add EnableDevModeInDebug, but we likely shouldn't. This can be set by an App Setting on a staging site (or slot), which makes it much more deterministic.
Alternatives
Setting the environment string in
AZURE_FUNCTIONS_ENVIRONMENT
as an app setting lets you explicitly control this.Detection
Since this is a value passed to the FunctionsStartup, I don't know if we can determine how many customers are reading it. If needed, we could log an event in the getter.
Support
Hopefully this reduces support cases; there should be no explicit support education required.
Documentation
AZURE_FUNCTIONS_ENVIRONMENT
is already documented (and in fact, the current behavior is incorrect based on documentation): https://docs.microsoft.com/en-us/azure/azure-functions/functions-app-settings#azure_functions_environment.Components impacted
Host
Core tools already explicitly sets this to "Development": https://github.com/Azure/azure-functions-core-tools/blob/dev/src/Azure.Functions.Cli/Actions/HostActions/StartHostAction.cs#L225-L226
Performance
No perf impact.
The text was updated successfully, but these errors were encountered: