Azure Deployment Slots Pricing
In this video of the Azure Portal “How To” Series, you will learn how to set up staging environments in Azure App Service by using deployment slots. Adding Custom Modules to an Azure Deployment. Adding Project's Code and Items to the Azure Deployment. In the previous post, we completed our Sitecore Azure setup, including a custom module and our initial project. At this point, we want to setup Azure staging slots, so the next release of our project can go there. Azure Cloud Services is another platform Azure Service offering. Like Azure App Service, it is designed to support applications that are scalable, reliable, and inexpensive. The key difference between Azure App Service and Cloud Service is that with the Cloud Service you have more control over the virtual machines hosting your services.
There are a lot of different ways to integrate Dynamics with different systems - Flow, KingswaySoft SSIS, Scribe, Azure Functions, etc. All of them can suit a different kind of scenarios and might be not applicable to others. For one of our integrations, we are using Azure Functions. It is a simple API that can be used by 3rd party systems. Last week I got a task - provide an API for the testing purpose that should be connected to our dev Dynamics instance. And that API should be the same as we already have. After some searching, I found an answer - Azure Deployment Slots.
So what is Azure Deployment Slot? Quote from Microsoft:
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.
Basically, slots provide you with an ideal solution for testing everything on the near-live environment and being able to rapidly deploy changes to production with no downtime and in case if something went wrong rollback to the previous state. Also, you can have different slot specific app configuration that will not be swapped allowing you to create much more sophisticated usage scenarios.
Create Deployment Slot
First of all, you need to go to the Azure Portal and open your function app. Under your function app, you can see Slots (Preview) section. Press + sign to create a new slot (see picture below). An important note here: under Consumption Plan you can have just one additional slot.
After you click on + button you Create a new deployment slot blade will open. Here you need to type the name of your Slot. It will be used to generate URL for your slots azure function instance. For example, you will name your slot Development and your URL will look something like that:
your_function_name-development.azurewebsites.net
It will take some time for Azure to create your deployment slot. After it will be created you will need to upload your function to that slot. You can do it using Visual Studio. Open your functions app project, press Publish and create a new profile. There select the existing App Service and select your deployment slot. That’s it. Now you can publish your code to your deployment slot.
Create slot aware application settings
Next thing that you definitely need to know is how to create slot aware application settings. Application settings are global configuration options that affect all functions inside function app. To create an application setting open your function app then select Configuration. It will open Application settings blade. There select New application settings
This will open Add/Edit application blade. There you can type the Name of the setting and Value for it. Notice that there is a checkbox under Value field called “deployment slot setting”. If you checked it this setting won’t be swapped. Don’t forget to create settings on both your production and development slot and mark them as “deployment slot setting”.
Now, when we created an application setting we need to know how to use them in code. For example, I created two settings called MyQueue and MyConnection. MyQueue will contain the name of the queue that I will use to trigger my queue function. And MyConnection will contain connection string to my CRM instance. Let’s say we have a function called MySimpleQueueFunction and we want to connect it with our queue. To do so we need to wrap the variable name in the code with % sign (see code below).
But what should we do if we need to use our setting inside the function itself? Well, Microsoft provided us with this simple function:
And to get value from our variable we can do something like that:
Great we are almost done. Now if we wanted to use these variables in local development we need to specify them in our local.settings.json file.
How to perform a Swap
Last, but certainly not the least is the Swap process itself. When you tested everything and ready to deploy your changes to production you need to do next: select your dev function. You can see Swap button (see image below).
It will open the blade with swap information: Source and Destination. Select development as Source and production as Target. Then press Swap button. Also, you can see what settings will be changed after the swap in Config Changes tab. And that’s it. Azure will take care of swapping everything.
If you want to know more about what happens during the swap you can check it here.
That’s it. I hope this information was useful for you. I didn’t cover here a lot of things like auto-swap feature and other things as this article is just an introduction to deployment slots. If you want to know more please visit Microsoft official documentation page for Azure Deployment Slots (here).
If you liked this article, please subscribe so you don't miss any future post.
Recent post
Every App Service resource in Azure has the ability to have multiple deployment slots configure. These deployments slots are a feature than can greatly help with the implementation of streamlined testing, staging, and deployment process. Along with the ability to configure multiple hosting environments, the use of Deployment Slots enables zero downtime when deploying application changes, or even rolling back a failed deployment.
Azure Deployment Slots Pricing List
Creating Deployment Slots
Deployment slots are a feature of Azure App Service Plans. As a result, every App Service resource (Web App, Web API, Mobile App) in Microsoft Azure has the ability to create up to 4 additional deployment slots with the Standard tiers, and up to 20 deployment slots with the Premium tiers.
Each App Service (in Standard tiers) can have up to 4 additional Deployment Slots in addition to the Production slot.
Each Deployment Slot allows for a separate instance of the application to be hosted in isolation from the other deployment slots and production slot of the App Service. The VM behind each Deployment Slot is the same VM Instance that hosts the production deployment slot. This means that the App Service and 4 additional Deployment Slots will all be hosted in and share the same VM Instance and resources.
To create App Service Deployment Slots in the Azure Portal, just navigate to the App Service, select the Deployment slots section and click the Add Slot button to create a new Deployment Slot.
Additionally, in order to use the Deployment Slots feature of Azure App Service, the pricing tier must be either Standard or Premium. The Free, Shared, and Basic pricing tiers do not support deployment slots.
It’s important to keep in mind that all Deployment Slots share the same VM Instance and server resources.
Deployment Slot URL / Endpoint
Azure App Service applications get a unique URL that is made up of the App Service Name as the subdomain of the azurewebsites.net domain. In the above screen shot, the App Service Name is “testapp2063” which means the URL / endpoint for the Production slot of the App Service is located at testapp2063.azurewebsites.net.
When creating Deployment Slots each slot gets it’s own URL / Endpoint. The endpoint for each deployment slot derives from the endpoint for the Production slot by appending the name of the deployment slot with a hyphen.
With an App Service named “testapp2063” the URL / Endpoint for the following deployment slots will have the following values:
- dev => testapp2063-dev.azurewebsites.net
- test => testapp2063-test.azurewebsites.net
- stage => testapp2063-stage.azurewebsites.net
Deployment Slot Swapping
Swapping Deployment Slots is the method of copying the currently deployed application code and settings of one deployment slot and swapping it with another. Swapping allows for the deployment of application code to be done from one environment to another very quickly. It also allows for a couple new deployment techniques that didn’t exist in traditional server hosting.
Azure Deployment Slots Pricing
To swap Deployment Slots from the Azure Portal, just navigate to the list of Deployment Slots for an App Service or navigate to the specific Deployment Slot that needs to be swapped. Then, click the Swap button and specify which Deployment Slot to swap with. See the above screenshots for reference of where the Swap button is located within the Azure Portal.
When an application is deployed using Deployment Slot swapping, there is zero downtime
When an application is deployed using Deployment Slot swapping, there is zero downtime of the application. The way this is implemented is by just rerouting the Deployment Slot Endpoint between the Deployment Slots being swapped. Both deployment slots remain running and actively responding to client requests throughout the swap.
Staged Deployment
The technique of performing a Staged Deployment allows for application code to be deployed to a non-production deployment slot (such as one named stage) to test or verify functionality is working as expected. Then once everything has been verified, the Stage deployment slot can be swapped with Production making the staged application deployment the new Production instance of the application.
Incremental Deployment
There are times when deploying application changes might require additional changes other than just deploying the latest code. These requirements could be running SQL scripts or some other post deployment step necessary to fully deploy the latest code. Deploying to a Stage deployment slot can allow for these Incremental steps to be performed after the code is deployed in a way that can be tested and verified before deploying to production.
Rollback Deployment
Every once in awhile a deployment fails for some reason. Maybe files end up corrupt, a major bug is found, or some other reason for failure. In these cases, it’s necessary to rollback a deployment. Using Deployment Slots, a deployment can be rolled back easily buy just swapping the Deployment Slots back.
Basically, swap Stage with Production to deploy new changes. When a major bug is found that requires a rollback, then the Production and Stage Deployment Slots can be swapped back. This allows for the old application code to be rolled back into Production in a matter of minutes. This leads to greatly decreased downtime in the event of a deployment failure.
Azure Deployment Slots Pricing Guide
Chris is the Founder of Build5Nines.com and a Microsoft MVP in Azure & IoT with 20 years of experience designing and building Cloud & Enterprise systems. He is also a Microsoft Certified: Azure Solutions Architect, developer, Microsoft Certified Trainer (MCT), and Cloud Advocate. He has a passion for technology and sharing what he learns with others to help enable them to learn faster and be more productive.