Can we use same function app for prod and dev environment ?

Question

Can we use same function app for prod and dev environment ?
The challenge is that we have multiple environment-specific app settings in the Function App, such as storage account name, AzureWebJobsStorage and other Server connection, which differ between DEV and PROD environments. Despite these differences, we are planning to consolidate and use the same Function App for both environments.

Is this feasible, and if so, what would be the best way to manage the environment-specific configurations?

Answer 1

To clarify you want to deploy a single function app that supports multiple environments? This isn't the same as taking the same function app code and deploying it multiple times to different environments. I'm assuming you're talking about 1 deployment for all environments.

Can you do it? Theoretically? Yes. Is it recommended? No.

On the theory side you can have a single app that relies on some input parameter to tell it what "environment" to use. Within your standard app settings you would distinguish between environments by prepending or appending some value to the name (e.g. ConnectionString_Dev, ConnectionString_Prod). It is then up to your code to determine which setting to use based upon what it is called with. You cannot rely on some things that normally work out of the box such as the ability to configure your connection string and associate it with your database connection automatically at startup because now that information is only available during a request. So you're going to have to write your own code that determines the correct connection string, in this case, to use and then creates the appropriate DB connection rather than relying on DI to handle all this.

But this isn't really recommended for any # of reasons.

1. Your code is now going to get more complicated because you need to juggle the "environment" stuff yourself rather than dealing with this at startup and it just working via DI after that.
2. It is going to get more difficult as you add more environments. You will either need to generalize your support or update your code for each new environment.
3. Generally non-prod environments are run against free or low-cost resources while production is run against standard or performant resources. Things like scaling and VM selection impact this. Having a single function app means you'd need to run all your environments as though they are in production.
4. Related to this is the fact that if you are testing in non-prod then you are actually impacting production since you are using the same instance. If you accidentally, for example, deploy a change that eats up all resources then production goes down. Keeping your environments separate is both a good security and performance practice.
5. Separation of environments is also very important because something has to tell your function app which environment to use. In general this is controlled by exposing URLs in some cases and/or using security to lock things down. You cannot easily do this if you have a single function app. Presumably you'd need some parameter to tell the app which environment to target but how do you enforce who does that or even ensure it is correct. It would be quite easy to have test code pass the wrong data and be testing in prod instead.

In general you have a single function app that you build and then you deploy it to each environment you want to support. Each deployment has its own set of app settings so you have the clean separation and your code doesn't need to do anything special. Your non-prod environments you can use the free or low-cost tiers to test while the production is using a higher tier to meet your performance needs. The only real benefit of having only a single copy of a function app is that you don't have to deploy to multiple environments but deployments are a small part of the lifetime of an app so it really shouldn't be that big of a deal.