Q:

Different environments in Azure shared app service plan

Recently I've started experimenting and getting familiar with some of the Azure offerings.   I made a simple app, connected it with azure functions and azure storage as well as some other offerings like service bus for example. 
So far so good, the app is working great and I got my feet wet with some great Azure services. 
But now I'm unsure on how best to proceed because what I have so far is a development version of my app.   If I wanted to make a prod version do I have to provision a different set of all the azure resources used for the dev version? 
So basically, I would have mydevsite.azurewebsites.net and myprodsite.azurewebsites.net.   Is this correct?   I can restrict mydevsite.azurewebsites.net with some IP address restrictions so that is not publicly available but I still feel this is a hacky way of doing this and that there should be a better way. 
Is there a common approach to a scenario like this? 

A:

This is a bit of a broad question, but I can tell how I have done it before. 
A common setup would be three environments, Dev, Test and Production. 
Dev mostly runs on the developer's machine (as much as it can).  We use a local IIS installation to run the web app, and a local SQL Server as a database.  Azure Storage and Cosmos DB can also be emulated locally.  Certain services like Search for example can't be run locally so you would have to run those in Azure anyway. 
Test and Production are basically two identical resource groups with the same resources, just configured slightly differently.  So double the App Service Plans, SQL databases etc. 
Depending on how you want to do it though, you can of course share resources across environments.  But it is a good idea to somehow make sure they do not accidentally use the other environment's stuff.  And the definite bad side of this is that you are putting production data in the same place as test data, which frankly should not be together. 
I know some organizations run a Dev environment fully in Azure.  There can be a couple reasons for this: very heavy environment which can't really run on dev machines, or they want to test ARM template deployment at dev stage too. 
Having duplicated services allows you to use ARM templates for automatically deploying and updating the infrastructure, which is pretty nice. 
If you are on Standard or higher, you might think to use Deployment Slots in App Service for different environments, but they are really not meant for that purpose.  We use them to reduce application downtime when deploying a new version, and as a fallback if the update turns out bad.  So the deployment goes to a "staging" deployment slot, which gets swapped with the other one, and the new version is live.  We then stop the deployment slot so we are not running the older version in the background unnecessarily. 
But otherwise we have a separate App Service Plan with separate Web Apps with their own staging slots. 
Deployment slots documentation: https://docs.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing

