VSTS

I did an event yesterday on using the TFS Database Import Service to do migrations from on premises TFS to VSTS. During the presentation I discussed some of the other migration options available. Not everyone needs a high fidelity migration, bring everything over. Some teams may want to just bring over their current source or just a subset of their source. Maybe they are making a major change in work practices and want to start anew on VSTS. To try to give an idea of the options I have produced this flow chart to help with the choices ...

Updated: 5th Aug 2016 added notes in PublisherID I have been developing a few VSTS/TFS build related extensions and have published a few in the VSTS marketplace. This has all been a somewhat manual process, a mixture of Gulp and PowerShell has helped a bit, but I decided it was time to try to do a more formal approach. To do this I have used Jesse Houwing’s VSTS Extension Tasks. Even with this set of tasks I am not sure what I have is ‘best practice’, but it does work. The doubt is due to the way the marketplace handles revisions and preview flags. What I have works for me, but ‘your mileage may differ’ ...

**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. However there is a problem, both the first two options need administrative access as they put the Pester module in the $PSModules folder (under ‘Program Files’); so these can’t be used on VSTS’s hosted build system, where your are not an administrator So this means you are left with copying the module (and associated functions folder) to some local working folder and running it manually; but do you really want to have to store the Pester module in your source repo? My solution was to write a vNext build tasks to deploy the Pester files and run the Pester tests. The task takes two parameters ...

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. To this end I have written a new StyleCop task that can be found in my vNext Build Repo, this has been built to use the 4.7.49.0 release of StyleCop (so you don’t need to install StyleCop in the build machine, so it works well on VSTS). To use this task: ...