Tag Archives: App Service

Per-environment config value tokenization for Azure Web Apps using VSTS Release Management

For the majority of the last ten years I’ve been working with delivery of solutions where build and deployment comes from some centralised location.

When Microsoft made InRelease part of TFS as Release Management, I couldn’t wait to use it. Unfortunately in its state at that time the learning curve was quite steep and the immediate value was outweighed by the effort to get up and running.

Roll forward to 2016 and we find Release Management as a modern, web-based feature of Visual Studio Team Services (VSTS). The cherry on the cake is that a lot of the learning curve has dropped away as a result.

In this post I’m going to look at how we can deploy a Web Deploy (or MS Deploy) packaged Web Application to an Azure Web Application and define different deployment environments with varying configurations.

Many people would apply configuration transformations at build time, but in my scenario I want to deploy the same compiled package to multiple environments without the need to recompile anything.

My Challenge

The build definition for my Web Application results in a package that allows it to be deployed to an Azure Web App by Web Deploy. The result is the web.config configuration file is in a zip file that is transferred to the server for deployment by Web Deploy.

Clearly at this point I don’t have access to the web.config file in the drop folder so I can’t transform it with Release Management. Or can I?!

Using Web Deploy Parameters

Thankfully the design of Web Deploy provides for the scenario I described above though use of either commandline arguments or a specially formatted input file that I will call the “SetParameters” file.

Given this is a first-class feature in the broader Microsoft developer toolkit, I’d expected that there would be a few Tasks in VSTS that I could use to get all of this up and running… I got close, but couldn’t quite get it functioning as I wanted.

Through the rest of this post I will walk you through the setup to get this going.

Note: I am going to assume you have setup Build and Release Management definitions in VSTS already. Your Build should package to deploy to an Azure Web App and the Release Management definition to deploy it.

VSTS Release Management Setup

The first thing to get all of this up and running is to add the Release Management Utilities extension to your subscription. This extension includes the Tokenizer Task which will be key to getting the configuration per-environment up and running.

You also need to define an “Environment” in Release Management for each deployment target we have, which will also be used as a container for environmental configuration items to replace at deployment time. A sample is shown below with two Environments defined


We’ll come back to VSTS later, for now, let’s look at the project changes you need to make.

Source Project Changes

For the purpose of this exercise I’m just worrying about web.config changes.

First of all, you need to tokenise the settings you wish to transform. I have provided a sample below that shows how this looks in a web.config. The format of two underscores on either side of your token placeholder is required.

The next item we need to do is to add a new XML file to our Visual Studio project at the root level. This file should be called “Parameters.xml” and I have included a sample below that shows what we need to add to if it we want to ensure we replace the tokens in the above sample web.config.

You’ll notice one additional item in the file below that isn’t related directly to the web.config above – the IIS Website name that will be used when deployed. I found if I didn’t include this the deployment would fail.

When you add this file, make sure to set the properties for it to a Build Action of “None” and Copy to Output Directory of “Do not copy”.

Note: if you haven’t already done so, you should run a Build so that you have Build Artifacts ready to select in a later step.

Add the Tokenizer to your Release Management Definition

We need now to return to VSTS’ web interface and modify our existing Release Management definition (or create a new one) that adds the Tokenizer utility to the process.

You will need to repeat this so all your environments have the same setup. I’ve shown how my Test environment setup looks like below (note that I changed the default description of the Tokenizer Task).

Release Management Definition

Configuration of the Tokenizer is pretty straight forward at this point, especially if we’ve already run a build. Simply select the SetParameters.xml file your build already produced.

Tokenizer setting

Define values to replace Tokens

This is where we define the values that will be used to replace the tokens at deployment time.

Click on the three dots at the top right of the environment definition and from the menu select “Configuration variables…” as shown below.

Variable Definition

A dialog loads that allows us to define the values that will go into our web.config for this environment. The great thing you’ll note is that you can obfuscate sensitive details (in my example, the key to access the Document DB account). This is non-reversible too – you can’t “unhide” the value and see the plain-text version.

Token Values

We’re almost done!

Explicitly select SetParameters file for deployment

I’m using the 3.* (preview) version of the Deploy Azure App Service Release Management Task, which I have configured as shown.

App Service Task

At this point, if you create a new Release and deploy to the configured environment you will find that the deployed web.config contains the values you specified in VSTS and you will no longer need multiple builds to send the same package to multiple environments.

Happy Days! 🙂

Tagged , , , , , ,

Understanding Azure App Service Plans and Pricing

Like many things in Azure, Azure App Service has a multitude of consumption options available that can sometimes make it hard to determine what option suits your use.

In this post I’m going to walk through App Service, and for simplicity’s sake, I’m going to stick to deploying just Web Apps.

So, what do we have available and how does it best fit what I want to do?

Firstly, you can deploy more than a single app into a Plan at no additional cost. New apps will be deployed alongside existing apps and share the resource allocation available in Plan Tier (this is how the old Azure Websites worked, so not much has changed here).

Beyond this there are nuances that it’s worth exploring.

Free Tier (F1)

Charge Model: free

Does what it says on the tin – gives you some Azure App Service capacity for free.

Your application runs on shared infrastructure. You can deploy up to 10 apps into a single Free Plan.

As with anything free, there is a trade-off – with this tier you get a maximum of 60 minutes CPU daily, with 1 GB RAM, 1 GB disk space and no SLA. You also can’t use a custom domain or SSL.

Suitable for Proof-of-Concepts (PoCs) or simple dev/test. Recommendation to avoid for production use as there is no SSL or support (SLA) in place.

Shared (S1)

Charge Model: fixed per-hour charge.

Provides you with a small step up from the Free tier, but still not really aimed at production workloads.

Your application runs on shared infrastructure. You can deploy up to 100 apps into a single Shared Plan.

The Shared tier provides SSL and custom domain support along with additional CPU minutes per day (up to 240).

While still not backed by an SLA, this tier may be more suited to simple non-critical workloads (such a smartlink redirect hosts) where they may only be used occasionally during any 24 hour period and that some service disruption isn’t impactful on anyone. A 302 redirect doesn’t burn many of those 240 minutes ;).

Basic (B1 – B3)

Charge Model: per-hour charge based on number of instances.

For example: B2 tier (in USD in US West) with 3 instances = 3 x $0.15/hr = $0.45/hr

This is where App Service Plans meets production workload hosting. You are now running on dedicated instances and benefit from a 99.95% availability SLA. You can deploy unlimited apps into a single Basic Plan (though you’ll likely hit resource limits before hitting “unlimited” 😉 ).

You also have access now to manual scale-out (increase number of instances) and scale-up (shift from B1 – B2 – B3 tiers) options. Traffic is automatically balanced between your instances.

Limitations at this tier includes support for only a single SSL certificate per Plan. If you can leverage SNI then you can run multiple web apps on SSL. If not, it’s one app per Plan then!

If you need to connect to a private Azure network or use deployment Slots then this tier is also *not* suitable for you.

The Basic tier is a good starting place if you’re bringing an existing app into App Service, particularly if your current application is unlikely to support load balancing or auto-scale or does not require substantial resources to run.

Standard (S1 – S3)

Charge Model: per-hour charge based on number of instances.

For example: S3 tier (in USD in US West) with 5 instances = 5 x $0.40/hr = $2.00/hr

Standard tier provides everything Basic does (the instances are the same apart from increased disk space), but there are a few add-ons that make this a serious proposition for modern apps.

You gain additional SSL support (both SNI and IP address), additional scale-out support (up to 10 instances with auto-scale included), plus you can use automated daily backups, deployment slots and Azure Traffic Manager for geo-availability.

Slots (or “Staging Environments”) are a bit of grey area too – the “5” listed for this Tier means you get up to 5 slots per deployed Web App (note each slot shares the same pool of resources as your live site.. so don’t do stress / performance testing here 😉 ).

Premium (P1 – P4)

Charge Model: per-hour charge based on number of instances.

For example: P1 tier (in USD in US West) with 10 instances = 10 x $0.30/hr = $3.00/hr

The name says it all really – this tier offers the best features and provides you with access to dedicated App Service Environments (ASEs) that carve out private network space in Azure for just your Apps.

Beyond what Standard gives you, you now get support for up to 50 instances (more if you ask support nicely 😉 ) along with 50 daily backups and 20 slots.

It’s worth noting that maybe some of these costs sound substantial, but with each tier, as I pointed out at the start of the blog post, you can deploy multiple apps onto each instance at no additional cost. This means that you may have many similar apps that can co-exist and as such you could deploy them all into a single App Plan.

Note that there is currently a limitation around App Service Environments that means they can only leverage the classic “v1” virtual networking in Azure which could be an issue if you are using just the new Resource Manager model.

As of July 2016, App Service Environments now support the new “ARM” virtual networking model so you good to go if you need to provision via this method.


As you can see, there is a lot of flexibility available when hosting Web Apps in App Service. If you have lots of small web apps that can coexist on the same machines (a fairly typical model in traiditional web hosting) then you should look closely at App Service as a solution to your needs in Azure.

Finally, Microsoft has even developed some tooling that can even help you figure out how to move – check out https://www.movemetothecloud.net/.

Happy days!

Tagged , , ,