The continuous deployment feature of Azure websites is special because it is just so simple. I won’t walk through the steps of setting it up. That is already done and done well here. It is especially sweet that you can just hook up your repository with the likes of GitHub, BitBucket, or Visual Studio Online with a simple OAuth authorization and it just works. After picking organization, repository, and branch, you’re off to the races. Your website just stays up to date with the selected branch on the selected repository. In times past, making this level of automation happen required build servers and complex configuration, lots of scripting and setup. Now it’s configurable in the Azure portal and it couldn’t be any more a breeze.
In addition to being able to continuously deploy, Azure has a feature call Deployment Slots. This means the same application can have multiple deployments. This is commonly used for having test environments and can be more cost-effective and easier to configure and maintain than using multiple Web Apps. It does, though, require using the Standard or Premium Pricing Tiers, so it may not be a free move if you’re not already there, but it will still cost less than using multiple sites in most cases, unless the non-Production environments leverage free sites. One way or another – with deployment slots or with separate sites - with multiple environments comes several questions about ways of distinguishing between the running applications in the different deployment slots and configuring them differently. The wonderful news is that they are easily configurable on their own. Continuous deployment can be set up to use different branches. Therefore, you can have sites available that are tracking each of your branches.
The Azure Portal, in the context of a selected Web App shows Deployment options.
This depicts the commit message of the currently built and deployed changeset in your source control and can be clicked to edit continuous delivery settings and shows the number of deployment slots with click capability to select and edit them. Having selected a deployment slot, you then have all the same options you have as for the root App, including being able to configure the deployment for that slot and custom domains for each slot (often using subdomains for different environments). It should be noted that I have not had success with trying to set up custom domains and SSL certificates in the new portal (it just reports that a failure happened when I try to save configuration without detail on what went wrong). To get that to work, I’ve had to go to the old portal. It just works there.
The next thing you need to consider if you are setting up multiple environments for an application via deployment slots is that most of the time, you need to configure them differently. Things like database connection strings and other configuration parameters may (should) vary from environment to environment. One way to do this is to configure your application in your web.config for your local development environment and to use the configuration override capability of the Azure Portal. This is a passable solution and works for the AppSettings and ConnectionStrings elements fine enough, but I can think of two reasons I find it unsatisfying. It requires going to a website for setup anytime there’s anything that needs to change, which is much less efficient than just changing a configuration file and committing the change to source control. It is also limited to those configuration sections mentioned before. This is fine in most cases, but sometimes, especially if you are using third-party libraries and such, there may be some custom sections you want to specify differently in different environments. This is the problem solved by using the Web.config transforms introduced with .NET 2.0.
Brian Vallelunga (and commenter Amit Apple, whose blog is worth following) has done us the service of sharing how to make Web.config transforms execute and deploy when using continuous deployment from source control in Azure. By simply adding a target to your Web Application project file and creating an setting in AppSettings in the Azure portal, you are able to use an environment-specific Web.config transform automatically on deployment. This was exactly the answer I sought. Thanks Brian and Amit!