When to use Deployment Slots vs Separate App Services when deploying different versions of an App Service

I had a question regarding deployment slots because I am trying to figure out the way I want to use the deployment slots is acceptable or not. In our team we tend to have 3 environments for most of our web applications :

• DEV - latest dev code
• QA - code that QA is actively testing
• BC - lastly a separate environment again for QA to run backward compatibility tests

Currently we are given a single app service resource. Since we would like to maintain 3 versions of the application code deployed for said 3 environments, I was wondering if 3 separate deployment slots could be leveraged for it, or would creating 3 separate web apps is the way to go?

From the doc I know that the deployment slots are meant for quick testing and then swapping it out to production but since we are currently limited to single instance of web app I was thinking of leveraging deployment slots.

I would like to know your thoughts on this and if I should go with new app services or slots for these kind of scenario.

Just to add separating them out is the more flexible and potentially a more secure way to go. As mentioned there is not cost difference; however, I'd like to point out that if web apps will truly be 3 different environments then they should be 3 different app services. This will enable you to have a database behind each environment, an Identity assign to each environment, Application registration and potentially different access restrictions rules for each environment.

In fact there could potentially be a cost savings separating them out as the app service in DEV might be more scaled down then in PROD. Or DEV could be just deleted off when not in use and redeployed via ARM when being worked on.

From Microsoft Best Practices on app service slots it calls out using a slot for:

> - You can validate app changes in a staging deployment slot before swapping it with the production slot.
> - Deploying an app to a slot first and swapping it into production makes sure that all instances of the slot are warmed up before
> being swapped into production. This eliminates downtime when you
> deploy your app. The traffic redirection is seamless, and no
> requests are dropped because of swap operations. You can automate
> this entire workflow by configuring auto swap when pre-swap
> validation isn't needed.
> - After a swap, the slot with previously staged app now has the previous production app. If the changes swapped into the production
> slot aren't as you expect, you can perform the same swap
> immediately to get your "last known good site" back.

For further clarification deployments slots should be used for Blue-green deployment or canary releases This link is for DevOps deployment but same concept applies for app service slots.

Of course the downside is potentially some more overhead and management. If separate app services then potentially separate DNS records, network rules, SSL certs, etc..

Technically I believe it is possible to do what you are suggesting because each deployment slot does host a fully functional version of your application and you can access specific slots using this routing method. You would simply deploy each environment to its own slot and never swap them.

However, there is no reason to do this. You can create additional web applications at no cost. You are only paying for the App Service Plan, and you can have as many web apps running on that plan as you want, so you would be better off creating a separate App Service for each of your environments, and since they are all non-production, you can safely run them all in the same App Service Plan.