Caught myself loving on an MS service

Now this isn't an opinion/emotion I am very familiar with, not being unkind to Microsoft, but I find (or have found) a lot of their services 'acceptable' but given a choice I would often go elsewhere. Not so today.

Today, I was speaking to a colleague who is a .Net programmer but who chooses to use a mixture of the Atlassian stack and Github for; source control, issues, discussion, code reviews etc. After hearing how the various parts of this stack are integrated (or not) and the hoops that are jumped through the get the thing to just work (and the resulting fagility of the system) I asked if he'd looked at VSTS.

Now I realise VSTS doesn't cover all of the aspects of the process that he is using, but talking to him about what it could do and how it could integrate with, for example Github if you really wanted to continue to use that for source control, without compromising the rest of the product integration, I found myself being very supportive of the platform.

And I think what really struck me was that Microsoft have done such a great job in making VSTS so flexible and capable. Use your own source control, use your own build agents, use your agents inside your own network and deploy to Azure or deploy to in-house servers, it's all possible and embraced by VSTS.

You even have the ability to build your own custom build and release steps if you feel so inclined! And the ones that are available are all on Github to be inspected and reviewed.

Well done Microsoft, you've given me a first and I am pleased to speak on behalf of VSTS in future. Keep up the good work.

Provisioning Virtual Directories using ARM Template in Azure

This is as much a means to record what to do as to post a blog, but I recently ran into a requirement to deploy web packages to an Azure Web App using MSDeploy where the packages were to be uploaded to virtual directories/applications. The web app was being deployed using Azure Resource Manager (ARM) and I was struggling to find the correct syntax on how to define these directories.

After some searching I found this answer from David Ebbo with a PowerShell way of doing the same thing and wandered if I might modify this to work inside an ARM template.

https://social.msdn.microsoft.com/Forums/azure/en-US/990f41fd-f8b6-43a0-b942-cef0308120b2/add-virtual-application-and-directory-to-an-azure-website-using-powershell?forum=windowsazurewebsitespreview#0435503d-032e-429d-93ff-e106be04f556

It turns out that you can and the answer is quite straight forward. Rather than using the PowerShell structure, define your 'props' as JSON instead and since this is deploying a resource type of 'Microsoft.Web/sites/config' the whole configuration struct can be placed inside your website section as follows:

{
"type": "Microsoft.Web/sites",
"name": "[variables('requestSiteName')]",
"apiVersion": "2015-08-01",
"location": "West Europe",
...
"properties": {
"name": "[variables('requestSiteName')]",
...
},
"dependsOn": [
...
],
"resources": [
{
...
},
{
"apiVersion": "2015-08-01",
"name": "web",
"type": "config",
"properties": {
"virtualApplications": [
{
"virtualPath": "/",
"physicalPath": "site\\wwwroot"
},
{
"virtualPath": "/foo",
"physicalPath": "site\\bar"
}
]
}
}
]
}