Updated 22 Mar 2016: This task is now available as an extension in the VSTS marketplace A common request I get from clients is how can I create a custom set of release notes for a build? The standard TFS build report often includes the information required (work items and changesets/commits associate with the build) but not in a format that is easy to redistribute. So I decided to create a set to tools to try to help....

Azure provides many ways to scale and structure web site and virtual applications. I recently needed to deploy the following structure where each service endpoint was its own Visual Studio Web Application Project built as a MSDeploy Package http://demo.azurewebsites.net/api/service1 http://demo.azurewebsites.net/api/service2 http://demo.azurewebsites.net/api/service3 To do this in the Azure Portal in … Created a Web App for the site http://demo.azurewebsites.net This pointed to the disk location sitewwwoot, I disabled the folder as an application as there is not application running at this level Created a virtual directory api point to sitewwrootapi, again disabling this folder as an application Created a virtual application for each of my services, each with their own folder I knew from past experience I could use MSDeploy to deploy to the root site or the api virtual directory....

**Updated 22 Mar 2016 **This task is available in the VSTS Marketplace If you are using Pester to unit test your PowerShell code then there is a good chance you will want to include it in your automated build process. To do this, you need to get Pester installed on your build machine. The usual options would be Manual install from GitHub Install via Chocolaty Install via Nuget If you own the build agent VM then any of these options are good, you can even write the NuGet restore into your build process itself....

With the advent of TFS 2015.2 RC (and the associated VSTS release) we have seen the short term removal of the ‘External TFS Build’ option for the Release Management artifacts source. This causes me a bit of a problem as I wanted to try out the new on premises vNext based Release Management features on 2015.2, but don’t want to place the RC on my production server (though there is go live support)....

Brian Harry has done a couple of very interesting posts (post 1 and post 2) on the recent outages of the VSTS service. Whether you use VSTS or not they make interesting reading for anyone who is involved in running SaaS based systems, or anything at scale. From the posts the obvious reading is you cannot under estimate the importance of in production montoring having an response plan doing a proper root cause analysis and putting steps in place to stop the problem happening again Well worth a read

This a a repost of a guest article first posted on the Microsoft UK Developers Blog: How to extend a VSTS release process to on-premises Note that since I write the original post there have been some changes on VSTS and the release to TFS 2015.2 RC1. These mean there is no longer an option to pull build artifacts from the an external TFS server as part of a release; so invalidating some of the options this post discusses....

Whilst seting up a Release Management 2015.1 server we came across a strange problem. The installation appears to go OK. We were able to install the server and from the client created a simple vNext release pipeline and run it. However, the release stalled on the ‘Upload Components’ step. Looking in event log of the VM running the Release Management server we could see many many errors all complaining about invalid XML, all in the general form...

You can use the filePath type in a vNext VSTS/TFS task as shown below { "name": "settingsFile", "type": "filePath", "label": "Settings File", "defaultValue": "", "required": false, "helpMarkDown": "Path to single settings files to use (as opposed to files in project folders)", "groupName":"advanced" } to present a file picker dialog in the build editor that allows the build editor to pick a file or folder in the build’s source repository While doing some task development recently I found that this control did not behave as I had expected...

Updated 22 Mar 2016 This tasks is available in the VSTS Marketplace I have previously posted on how a PowerShell script can be used to run StyleCop as part of vNext VSTS/TFS build. Now I have more experience with vNext tasks it seemed a good time to convert this PowerShell script into a true task that can deploy StyleCop and making it far easier to expose the various parameters StyleCop allows....

Update 6 Feb 2016 - I have made some major changes to this task to expose more parameters, have a look at this post that details the newer version Today a good way to pull together all your measures of code quality is to run SonarQube within your automated build; in a .NET world this can show changes in quality over time for tools such as FxCop (Code Analysis) and StyleCop....