Top Tips for working with Deploying Azure App Services CI/CD Deployment Slots

Microsoft

Sep 24, 2019

CI/CD Best practice

A must read for all Developers is the following eBook Building Real World Cloud Apps with Azure: Best practices for DevOps, data storage, high availability, and more, by Scott Guthrie, Mark Simms, Tom Dykstra, Rick Anderson, and Mike Wasson.

This book explains 13 patterns and practices that can help you be successful developing web apps for the cloud.

Recommendations

The first two recommended development process patterns were Automate Everything and Source Control, and the third process pattern combines them.

Continuous integration (CI)

CI means that whenever a developer checks in code to the source repository, a build is automatically triggered. Continuous delivery (CD) takes this one step further: after a build and automated unit tests are successful, you automatically deploy the application to an environment where you can do more in-depth testing.

Continuous Integration and Continuous Delivery workflow

Generally we recommend that you do continuous delivery to your development and staging environments. Most teams, even at Microsoft, require a manual review and approval process for production deployment. For a production deployment you might want to make sure it happens when key people on the development team are available for support, or during low-traffic periods. But there's nothing to prevent you from completely automating your development and test environments so that all a developer has to do is check in a change and an environment is set up for acceptance testing. for more details see https://docs.microsoft.com/en-us/aspnet/aspnet/overview/developing-apps-with-windows-azure/building-real-world-cloud-apps-with-windows-azure/continuous-integration-and-continuous-delivery

For more information on the continuous integration and delivery features of Azure DevOps Services, see the Azure DevOps documentation.

If you're looking for a turn-key project management, team collaboration, and source control solution, check out Azure DevOps Services. Sign up at Azure DevOps Services.

Getting started with Azure DevOps

Simplify and speed up the DevOps process with Azure DevOps services. Azure DevOps Server Labs available now, you can learn how you can remove barriers between teams, encourage collaboration, and improve the flow of value to your customers. Simply Start Learning the labs will help you to get started with Azure DevOps services to automate software delivery and meet business needs. See https://azuredevopslabs.com/ for full details.

Example with Azure App Service Deployment slots

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. App content and configurations elements can be swapped between two deployment slots, including the production slot.

Using Deployment slots

Deploying your application to a deployment slot has the following benefits:

You can validate web app changes in a deployment slot before swapping it with the another slot.
Eliminate downtime on deployment, and automate the swapping.
Easy to swap a bad deployment back.

See https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots

Each App Service plan tier supports a different number of deployment slots. There's no additional charge for using deployment slots. To find out the number of slots your app's tier supports, see App Service limits.

To scale your app to a different tier, make sure that the target tier supports the number of slots your app already uses. For example, if your app has more than five slots, you can't scale it down to the Standard tier, because the Standard tier supports only five deployment slots.

Practice

Within the Azure Portal (https://portal.azure.com) you need to take the following steps:

In the Azure Portal, open the blade of your Azure App Service.
Click Settings, and then click Deployment slots.
In the “deployment slots” blade click on Add Slot.
In the “Add a slot” blade, give the slot a name, and select whether to clone web app configuration from another existing deployment slot.

The following Microsoft Doc has a full walkthroughs of developing deployment slots https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots

Top Tips

Before creating deployment slots you need to have a useful pattern. In my opinion it is best to use a deployment slot as a pre production environment. So in my case I use pre-production and production This will lead to the following solution architecture.

This solution architecture makes sure that the development/ test / acceptation environment is completely separated from production.

By simply utilising a pre production deployment slot you are able to test your application against the production SQL database. With this setup you can’t alter any data in pre-production this is why there is a dotted line between the pre production web app and the test / acceptation database. That you could use to test all your CRUD operations. Besides this is also makes sure that the pre production is as close to production as needed for a clear test results.

Considerations

When making use of deployment slots there are a considerations and disadvantages to be aware of:

The web application and deployment slots are created within the same environment (This is also the case when you create a Azure Web App within the same App Service Plan). This means resources between the two instances are shared, So if you want to do a stress test on pre-production you are certain that it will effect the performance of the production instanc see https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots.