Azure Cloud Service Deployment Slots

In this article, we will see –

  1. how to deploy Azure WebApp,
  2. add deployment slot,
  3. code push to Production and Staging slots
  4. finally, swap the slots

Design and Architecture of Azure Web App Deployment slots is given on the link below –


Deployment slots are very useful service from Azure cloud services, this isolate enviorment for developers to develope and test the codes in a seamless manner.The feature swap, enable the developers to rapid deployment and easy roll out roll back. For an example your web users connected and accessing the original production site on the. Navigate to your Azure App Service that you created in your environment. Click on ' Deployment Slots ' in the left panel and click ' Add Slot ' to create a new slot. Give it a name like ' staging ' so that you can identify it easily. When you deploy your web app, web app on Linux, mobile back end, or API app to Azure App Service, you can use a separate deployment slot instead of the default production slot when you're running in the Standard, Premium, or Isolated App Service plan tier. Deployment slots are live apps with their own host names.

Deploy Azure WebApp

  1. Login to Azure Portal –
  2. Deploy Azure WebApp using the New menu
  3. Click on Azure WebApp once it is created, click on “Deployment slots” and then click on “Add Slot”
  4. I have slot as “Staging”, and I have chosen not to clone configuration from Production slot. This is being done because we will be deploying different version of the app into both slots.

Summary –

Production URL –

Staging Slot URL –

Push code to Production and Staging deployment slots

  1. Launch VSTS and open sample web code. I have update the heading on the page to show – Production text. This will be published to the Production slot. Right click on the solution and click on Publish
  2. Select new profile, select Azure App Service. Choose Select Existing since we will be deploying to existing Azure WebApp
  3. Select the Primary slot – sarveshgoel and the code will be pushed there. We will run similar steps for Staging slot.
  4. Now click on Publish, and wait for the confirmation.
  5. Now browse the URL – and you would see the changes that we did initially

Deploy to Staging Slot now

Now repeat the process for Staging Slot but remember to modify the content of Web page, for example – I would change Production to Staging. Another change will from the steps above to deploy to Staging slot

Azure cloud service deployment slots software

Swap the Azure WebApp Deployment slot now

Now we have two versions of Web Application running on separate slots, running on their own Web URLs. As explained in the Design and Architecture documentation, purpose of staging slot is to test the code before making it Production.

Please remember, the slots in Production WebApp should be used for Staging environment but not for QA or testing environments.

Now, click on deployment slots on the Azure Portal, click on Swap . Now swap Production with Staging as shown below.

Once you click on Ok, Production becomes Staging and Staging becomes Production within few seconds.

Look at the URLs above, and try using this amazing feature Azure WebApp deployment slot.



When you deploy instances to a Cloud Service or add new web or worker role instances, Microsoft Azure allocates compute resources. You may occasionally receive errors when performing these operations even before you reach the Azure subscription limits. This article explains the causes of some of the common allocation failures and suggests possible remediation. The information may also be useful when you plan the deployment of your services.

If your Azure issue is not addressed in this article, visit the Azure forums on MSDN and Stack Overflow. You can post your issue in these forums, or post to @AzureSupport on Twitter. You also can submit an Azure support request. To submit a support request, on the Azure support page, select Get support.

Background – How allocation works

The servers in Azure datacenters are partitioned into clusters. A new cloud service allocation request is attempted in multiple clusters. When the first instance is deployed to a cloud service(in either staging or production), that cloud service gets pinned to a cluster. Any further deployments for the cloud service will happen in the same cluster. In this article, we'll refer to this as 'pinned to a cluster'. Diagram 1 below illustrates the case of a normal allocation which is attempted in multiple clusters; Diagram 2 illustrates the case of an allocation that's pinned to Cluster 2 because that's where the existing Cloud Service CS_1 is hosted.

Why allocation failure happens

When an allocation request is pinned to a cluster, there's a higher chance of failing to find free resources since the available resource pool is limited to a cluster. Furthermore, if your allocation request is pinned to a cluster but the type of resource you requested is not supported by that cluster, your request will fail even if the cluster has free resource. Diagram 3 below illustrates the case where a pinned allocation fails because the only candidate cluster does not have free resources. Diagram 4 illustrates the case where a pinned allocation fails because the only candidate cluster does not support the requested VM size, even though the cluster has free resources.

Troubleshooting allocation failure for cloud services

Azure Cloud Service Deployment Slots

Error Message

Azure Cloud Service Deployment Slots Free

You may see the following error message:

'Azure operation '{operation id}' failed with code Compute.ConstrainedAllocationFailed. Details: Allocation failed; unable to satisfy constraints in request. The requested new service deployment is bound to an Affinity Group, or it targets a Virtual Network, or there is an existing deployment under this hosted service. Any of these conditions constrains the new deployment to specific Azure resources. Please retry later or try reducing the VM size or number of role instances. Alternatively, if possible, remove the aforementioned constraints or try deploying to a different region.'

Azure Cloud Service Deployment Slots

Common Issues

Here are the common allocation scenarios that cause an allocation request to be pinned to a single cluster.

Azure Cloud Service Deployment Slots Download

  • Deploying to Staging Slot - If a cloud service has a deployment in either slot, then the entire cloud service is pinned to a specific cluster. This means that if a deployment already exists in the production slot, then a new staging deployment can only be allocated in the same cluster as the production slot. If the cluster is nearing capacity, the request may fail.
  • Scaling - Adding new instances to an existing cloud service must allocate in the same cluster. Small scaling requests can usually be allocated, but not always. If the cluster is nearing capacity, the request may fail.
  • Affinity Group - A new deployment to an empty cloud service can be allocated by the fabric in any cluster in that region, unless the cloud service is pinned to an affinity group. Deployments to the same affinity group will be attempted on the same cluster. If the cluster is nearing capacity, the request may fail.
  • Affinity Group vNet - Older Virtual Networks were tied to affinity groups instead of regions, and cloud services in these Virtual Networks would be pinned to the affinity group cluster. Deployments to this type of virtual network will be attempted on the pinned cluster. If the cluster is nearing capacity, the request may fail.


Azure Cloud Service Deployment Slots Software

  1. Redeploy to a new cloud service - This solution is likely to be most successful as it allows the platform to choose from all clusters in that region.

    • Deploy the workload to a new cloud service
    • Update the CNAME or A record to point traffic to the new cloud service
    • Once zero traffic is going to the old site, you can delete the old cloud service. This solution should incur zero downtime.
  2. Delete both production and staging slots - This solution will preserve your existing DNS name, but will cause downtime to your application.

    • Delete the production and staging slots of an existing cloud service so that the cloud service is empty, and then
    • Create a new deployment in the existing cloud service. This will re-attempt to allocation on all clusters in the region. Ensure the cloud service is not tied to an affinity group.
  3. Reserved IP - This solution will preserve your existing IP address, but will cause downtime to your application.

    • Create a ReservedIP for your existing deployment using Powershell

    • Follow #2 from above, making sure to specify the new ReservedIP in the service's CSCFG.

  4. Remove affinity group for new deployments - Affinity Groups are no longer recommended. Follow steps for #1 above to deploy a new cloud service. Ensure cloud service is not in an affinity group.

  5. Convert to a Regional Virtual Network - See How to migrate from Affinity Groups to a Regional Virtual Network (VNet).