If you have been using Azure web sites you might have heard of deployment slots. The idea behind slots is it gives you the ability to deploy an updated version of your application without replacing the existing production version. This way you can run validation tests on the new version before you make it live.
Slots offer you great freedom to verify your application before you turn on mistakes that can cost you money and hurt your brand image. Unfortunately deployment slots are only available in Standard and Premium plans. This means you must pay at least $74 per month for your App Service instance.
I know most web sites over allocate server resources, which means $74/month does not sound like much. But I know from experience you can host some very high demand sites and multiple high demand sites with less ‘hardware’ allocation. This means you should be able to host many typical application in the Basic plan without any performance degradation.
So with that, unless you want to spend more money than you should, you need another way to ‘mimic’ deployment slots in the Basic tier.
Since the last MVP Summit I have been using continuous deployment from my Visual Studio Online Git repositories to my Azure App Services. The great thing about App Services, once you chose the Basic tier you can create unlimited sites. Your only limitation is disk space, CPU and memory. Unless you deploy many binary files or lots of node modules you should be able to host several hundred sites in a Basic tier App Service plan.
With unlimited sites available you can create a new site for the development, QA and production version of your web application. If you have additional versions to deploy then add them accordingly.
Creating a site can be done through the portal, but I am starting to use a PowerShell script, which makes the process much easier. You can modify the script to automatically provision a site for each application version.
Once you have your sites provisioned you need to wire up your source code repository. My tactic is to create a branch that correlates to each site. I then connect the branch’s deployment to the correlating site version. This means I typically have 3 core source code branches: development, QA and Production.
I branch development work from the development branch and merge those changes back. When code is pushed to the origin (Visual Studio Online for example) the continuous deployment process initiates and the new version of the site is deployed.
Now I can test the live site and when I feel good about the code I can merge those changes to the QA branch and push. This of course deploys to the QA site. I repeat for Production.
While not a sexy as the deployment slot solution this works just as well and about $20/month cheaper.
This solution leverages my free Visual Studio Online Git repositories, but you could also use BitBucket, GitHub or other git host. Azure continuous deployment can also work with DropBox and OneDrive if you don’t use git as a source control solution. I prefer Visual Studio online because it is free for my personal code repositories and offers much more beyond source control. I will write more about VSTO in another article. To be honest I am still learning how to leverage Visual Studio Online completely.
The real difference between Basic and Standard App Service plans is disk space. Unless you have a very large disk footprint you can increase your profit margin in the Basic tier. If you look at a typical site the disk footprint should be less than 5MB if not well under a megabyte.
My solution allows you to have different stage deployment sites to verify before you push to production without spending an extra $20/month. I plan on writing how to create a continuous deployment from your source control to Azure App Services in some future articles. There is a little art to doing it properly and I think it is important to explain those details, but they are out of scope for this article. I hope this helps you create a good continuous deployment solution for your applications.