Azure Web Apps has a cool feature called Deployment slots. Using a deployment slot when deploying you application code to production has a few benefits:
- allows you to validate your web app changes in a staging deployment slot before pushing the changes to production web app
- By deploying a web app to a slot first and swapping it into production ensures that all instances of the slot are warmed up before being swapped into production. This eliminates cold start for your application. The traffic redirection is seamless, and no requests are dropped as a result of swap operations. You can also use Autoswap which means every time you push your code update to that slot, App Service will automatically swap the web app into production after it has already warmed up in the slot.
- Gives you the flexibility to rollback . After a swap, the slot with previously staged web app now has the previous production web app. If the changes swapped into the production slot are not as you expected, you can perform the same swap immediately to get your “last known good site” back.
Before using Deployment slots which gives you the ability to spin up multiple development environments to test and stage your application reducing risk downtime due to code deployment , you might have a few question on how to use them . Here are some questions I captured to help understand what you need to know before you start using this feature with your web app .
How many environments do I really need?
You can still host your development environment on your local machine, but in the cloud a minimum of two environments are required (Staging and Production). It is ideal to have to your development environment as well on Azure App service as there can be incompatibilities your code may not be able to detect on local environment just because your local development environment is different from azure app service environment.You should review Best practices for Web App development.
Should each environments be identical to production environment?
Keep staging and productions environments on the same App service plan, this make swapping between the environments easy through existing features with deployment slots. For your QA web app or development web app you can use a lower compute resources and replicate it to production environment as needed when you stress testing your application in a specific environment. You should include review Best practices for Web App development.
How to move web app between environments?
Deployment slots offer a SWAP feature to move between environments (production and/or non-production slots). Before using SWAP feature, you need to understand how other resources linked to your environment need to react.
For example, if your application requires a database then one solution is to SWAP both website and database across two environments. This reduces risk of issues as you can instantly roll back if there are issues. You many choose to SWAP just the websites and not the databases across environments, in such scenario you need to deploy your database updates from one environment to another and then swap the websites. If there are any settings that need to stick to an environment use slot setting checkbox as shown here.
Layout your plan for moving between environments and configure each environment accordingly.
Who can deploy versions to the next stage or environment?
In a team, there are different roles for team members. Role based access allows you to set permissions for users according to these roles (contributors, owners and reader roles). Build a governance plan for your web assets and set the appropriate roles to members who can deploy from development-to-Staging and Staging-to-Production. Of course, on some projects, the developer, the release manager, and QA tester may be the same person. The important point, though, is that there is always only one person responsible for deploying from one environment to another to maintain a strict deployment process for mission critical applications.
In order to maintain the integrity of the source code repository at no point does a team member make changes directly to the Staging or Production environments . Learn how to use Role based access for deploying code to your web app here.
How can I setup continuous integration from code repository when multiple people work on web app?
When you have multiple people working on a web app project and want to ensure that the latest version is always published regardless of who made the most recent update. Continuous deployment is also useful if you are using one of the above mentioned tools as the central repository for your application. You can use link different branches of your code to different environments. To learn more, click here.
What Coding standards to follow to deploy across environments?
To facilitate transfer of applications from the development server through the staging and into production, the code should be free of any environment specific variables i.e it must be stateless. Here are a few things to consider
- For example you can determine host name programmatically rather than specifying it explicitly in the code or in the configuration of your web application.
- To ensure code is portable across file systems use relative path names in code
- Set environment specific configuration in the app settings section if necessary set the base directory in the application’s configuration. This will enable applications and scripts to be moved from one directory on the development machine to another directory (possibly with a different path) on the production machine.
What pricing tier to choose?
Choose STANDARD tier or above for your mission critical applications. Note that deployment slots are supported ONLY for STANDARD, PREMIUM tiers only. For more information on pricing tier and features supported per tier, click here.
How to organize resources across environments
You can tag resources with name/value pairs to categorize and view resources across resource groups and, within the portal, across subscriptions. Tags can help you find and organize your resources. To learn more, see Organize your Azure resources with tags