Forget about managing servers – Azure App Service gives developers a ready-made platform to build web, mobile, and API apps. Plus, with Azure Functions built-in, you can create event-driven microservices that scale automatically, saving time and resources. Instead of managing servers, simply leverage Azure App Service to deploy your web applications and even non-web applications like mobile backends. This service handles hosting for web apps, APIs, and other HTTP-based applications, allowing you to focus on building amazing features. Several Apps like – web applications, web jobs, batches, APIs, and mobile backend services(for Mobile Front end to consume) can be hosted.

Just like choosing the right size apartment, Azure App Service plans offer various options for CPU and memory, allowing you to tailor the resources to your web app’s specific needs. This ensures optimal performance and cost-efficiency. Imagine an App Service plan as a flexible cloud server with adjustable performance. By choosing a plan in a specific region, you secure compute resources like CPU and memory. The beauty is, multiple apps can share these resources, scaling automatically as their needs fluctuate.

Azure App Service is your one-stop shop for building, deploying, and scaling powerful web apps and APIs. Choose from popular languages like .NET, Python, Node.js, and more, whether you prefer traditional coding or containerized setups. App Service automatically adjusts resources to handle sudden traffic spikes, ensuring your apps are always available and performant. Plus, say goodbye to manual deployments – integrate with GitHub, Azure DevOps, or your favorite IDE for smooth, automated releases.

Deployment Slots

Azure App Services lets you test and refine your web app in complete isolation with Deployment Slots.  Deployment slots are the feature provided by Azure App Service which will help to create different testing environments for deploying and testing your application. With this, we can test our app thoroughly before moving the code to live production environment. In Azure app service, each deployment slot act as a separate instance of the app. Each deployment slot will have its own configuration settings and dependencies.

This empowers you to experiment, iron out bugs, and confidently deliver top-notch experiences, all within the trusted Azure cloud.

There is no extra cost associated for the deployments slots and it is part of the Azure App Service plan. Only Standard and premium App service plans are having deployment slots whereas Free/Shared tier will not have deployment slots.

How Swap works

There will be only one deployment slot by default, and it will be production slot. By Default, 100% of the traffic would be going to the production slot.

Assume a scenario, we have an application and hosted in Azure App service with Premium tier App service plan. If the application name is utilitywebapp, then the production URL will be like “utilitywebapp. azurewebsites.net “ and this will be the production version of the application and the users can able to access it. The production version app would point to production DB in this case.

Now there is a bug in production where it requires a code change in your application. We usually make the code change in our local and unit test it and then promoting to DEV/QA environment for system/integration testing and then can promote it production. But it would be helpful if we can be able to test in production environment with our changed code version why because it is kind of opportunity to test and fix if the defect is related to any infrastructure or environment issues. We can foresee or visualize how our changed code would behave in production environment.

The deployment slots facility in Azure App service comes to the rescue. We can create deployment slots in Azure portal and can name it as “staging” and can deploy the changed code version in the environment. The URL for this environment is going to be like “utilitywebapp-staging. azurewebsites.net” and users can be able to access this URL. This staging environment is a virtual environment where we can deploy, validate our defect fixes, and add features without impacting the production environment. The staging environment would point to staging DB in this case during the deployment.

If we want to validate the fixes and to visualize how it would behave in production, the staging environment can point to production DB.

Switching between deployment slots

Here are the general steps to switch deployment slots in Azure App Service without any downtime:

• Create a new deployment slot: In the Azure portal, navigate to your App Service, and under “Deployment slots” click on “+Add slot” to create a new deployment slot.
• Deploy new version to the staging slot: Deploy the new version of your application to the staging slot.
• Test the new version: Test the new version of your application in the staging slot to ensure that it is working as expected.
• Start traffic routing: In the Azure portal, navigate to your App Service, and under “Deployment slots” click on “Traffic routing” and configure the traffic split between the production and staging slots.
• Monitor traffic: Monitor the traffic split between the production and staging slots to ensure that it is working as expected.
• Switch the production slot: When you are ready, switch the production slot to the new version of your application by swapping the slots.
• Remove the old slot: Once the new version is stable and all traffic is being served by it, you can remove the old slot.

Note that this method allows you to reduce the downtime by gradually redirecting the traffic to the new version of the app, but there still may be some downtime during the process of swapping the slots. You could also use Azure Traffic Manager to route the traffic based on a set of rules, such as geographic location, to minimize the impact of the swap.

Deployment slots – Key things

• Effortlessly Test Updates: Run multiple code versions concurrently on the same infrastructure using deployment slots. This allows for thorough testing before promoting changes to production.
• Multiple Environments: Create dedicated slots for development, staging, and testing, providing isolated spaces for each stage of your development process (beyond the default production slot).
• Progressive Rollouts (Optional): Route a controlled percentage of live traffic to non-production slots, enabling a gradual rollout of new features and risk mitigation.
• Broad Compatibility: While not available for all App Service plans, deployment slots offer a powerful feature for supported tiers.
• Seamless Swapping: Production slots are pre-warmed before switching, ensuring zero downtime deployments. Traffic redirection during swaps is smooth, preventing dropped requests.
• Flexible Control: Initiate swaps manually through the Azure portal or configure automatic deployments. If needed, a rollback option allows you to revert to a previous version.

Conclusion

Deployment Slots provide you with the benefit of having great flexibility to manage and test multiple versions of your app simultaneously, providing a reliable and controlled deployment process that maximizes user satisfaction and minimizes disruptions. With this feature, you can reduce the release risks of your apps and ensure a smooth transition between the different versions of your apps.