Update TFS Build Controller via Powershell

October 21, 2014

During a trial-migration of TFS, I typically prepare a lot of command-line tools to run some background update processes. Instead of writing little C# command-line applications in Visual Studio, I’m moving more and more away from Visual Studio and do stuff via PowerShell.

For a migration upgrade from TFS 2010 to TFS 2013, I have to deal with an update of the Build Controller to a new build machine/server. For a Team Project Collection of 100+ Team Projects and lots of build definitions, this is not something you want to do manually or delegate to all involved dev teams.

Instead of having to start from zero, I found this interesting post from Daniel Mann which does exactly what I want: updating the Build Controller from PowerShell via the TFS API. Except, it does it specifically for one dedicated Team Project.

So, the PowerShell script only needed a bit of tweaking to fetch all available Team Projects via the ListAllProjects method of the ICommonStructureService interface.

param(
[Parameter(Mandatory)]
[ValidateNotNullOrEmpty()]
[string]
$TfsUrl,
[Parameter(Mandatory)]
[ValidateNotNullOrEmpty()]
[string]
$NewBuildController,
[Switch]
$WhatIf
)

Function SetBuildControllerForTeamProject($TeamProject, $BuildController, $WhatIf)
{
$buildDefinitions = $buildClient.QueryBuildDefinitions($TeamProject)
$buildDefinitions | % {
Write-Host " >> Checking Build Definition" $_.Name
Write-Host " >>" $_.Name "is using" $_.BuildController.Name

if ($_.BuildController.Uri -ne $controller.Uri) {
Write-Host " >>> Setting" $_.Name "to use $BuildController"
if (!$WhatIf) {
$_.BuildController = $controller
$_.Save()
}
}
else {
Write-Host " >> Build controller is already set. Taking no action."
}
}
}

add-type -Path 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Common.dll'
add-type -Path 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Client.dll'
add-type -Path 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Build.Client.dll'

$tfsUri = new-object System.Uri $TfsUrl
$tpc = new-object Microsoft.TeamFoundation.Client.TfsTeamProjectCollection $tfsUri

$buildClient = $tpc.GetService('Microsoft.TeamFoundation.Build.Client.IBuildServer')
$commonStructure = $tpc.GetService('Microsoft.TeamFoundation.Server.ICommonStructureService')
$controller = $buildClient.GetBuildController($NewBuildController)

$allTeamProjectInfo = $commonStructure.ListAllProjects()
$sortedTeamProjectInfo = $allTeamProjectInfo | sort-object { $_.Name }

foreach($teamProjectInfo in $sortedTeamProjectInfo)
{
Write-Host '************** Scanning Build Definitions in Team Project' $teamProjectInfo.Name
SetBuildControllerForTeamProject $teamProjectInfo.Name $NewBuildController $WhatIf
Write-Host ''
}

You may also use the Community TFS Build Manager (Visual Studio 2013 extension) to modify a number of Build Definitions in bulk, but for my migration scenario, I preferred to have a PowerShell script. Having this script also allows me to modify other settings in the Build Definitions … for example the Build Drop Location.

Community TFS Build Manager


Update MSBuild Toolpath in TFS build process template

October 20, 2014

I have experienced a number of migration scenarios where it was decided to first upgrade old Visual Studio 2010 solutions to the latest and greatest version of Visual Studio (VS 2013 at this moment) without forcing a TFS upgrade at the same time.

Depending on the type of included projects for the Visual Studio solution, the TFS build might not work anymore because it requires other MSBuild .targets files (related to the .NET Framework version / Visual Studio version).

The easiest way to fix your TFS build failures is to modify the TFS 2010 build process templates and explicitly set the MSBuild ToolPath variable in the MSBuild activity to the upgraded Visual Studio version.

Visual Studio 2013 => C:\Program Files (x86)\MSBuild\12.0\Bin

MSBuild


Split test runs for TFS Build and inspect test results

September 22, 2014

As a consultant, many times I have to deal with custom requests which cannot be handled in TFS out-of-the-box. Many customizations end up to become valuable for other customers as well. Unfortunately I don’t always find the time to write about it and to work out a more generic solution which could help other people.

But recently I got an interesting question to intervene during the test run on the TFS Build Server because a complete test run took way too much time. The solution which was built on the server consisted of a big set of Unit Tests and a big set of Integration Tests. The Integration Tests required a deployment of a SQL Server database with some reference data. All tests were run at the same time and this caused builds to run for a long time, even if one of the Unit Tests failed at the beginning of the test run. The test run only completes (success/failure) after running ALL tests.

So, the goal was to quickly detect when a test fails (= fail early!) and to have the possibility to stop the build process immediately after the first test failure (=stop/fail build at the point one of the tests fails). The customer didn’t see any added value to run the remaining tests, knowing that already one test failed. Instead of waiting 30’ or longer for the full test results, the developers could already start fixing the first test failure and stopping the build would also decrease the load on the build server and test environment. We also agreed to only deploy the database when all Unit Tests succeeded.

How to separate the Integration Tests from the Unit Tests?

image

My sample solution above contains 2 separate projects/assemblies to host the Unit Tests and the Integration Tests. During the configuration of a Build Definition, you can easily define 2 separate test runs.

image

The first test run definition will only fetch the Unit Tests, while the second test run definition will look for the Integration Tests. Note that I specified a specific name for the test run definition. I will use this name later to filter the test run definitions. Creating multiple test run definitions is a flexible and easy way to split your big test run in multiple smaller test runs.

How to filter the test run definitions before the execution of a Test Run?

Time to customize the build process a bit so that first only the Unit Tests can be run before deciding to proceed with a database deployment and the run of the Integration Tests.

image

Instead of running the default VS Test Runner activity which would run all test run definitions (“AutomatedTests”), you need to filter for the Unit Tests. This can be done by modifying the TestSpec parameter for the RunAgileTestRunner activity. A where clause is added to the AutomatedTests value to search only for the “UnitTests” test run definition(s).

image

Result => only the Unit Tests will be executed by the VS Test Runner.

After this test run we can check the TestStatus of the build to stop the build or (in case of no test failures) to continue with a database deployment and the run of the Integration Tests.

In the ForEach activity after the database deployment operation I added a TestSpec filter for the AutomatedTests to only fetch the “IntegrationTests”.

image

The sequence in the ForEach activity will then call again the VS Test Runner and check for test failures to potentially stop the build in case of failure in the Integration Tests.

The more fine-grained you define your Integration Tests (= different test run definitions, making use of the test assembly file specification or the test case filter), the sooner you can inspect the test results and fail the build without running the other set(s) of Integration Tests.

Inspect Test Results during a Test Run (no filters)?

In the beginning, I started looking into options to inspect the test results during the ongoing one-and-only test run (no different test run definitions / no requirement for filters). I quickly stumbled on this MSDN page to learn more about the VSTest.Console.exe command-line options. By adding the switch /Logger:trx it’s possible to drop the test results into a Visual Studio Test Results File (.trx), but the problem is that the .trx file is only persisted to disk once the test run finishes. I didn’t find a way to get to the test results while the test run was still executing.

To stop the build in the customized build process template, I did throw an exception which is sufficient to stop the build process.

You can download the build process template which I used to write this blog entry. It’s far from complete and not fully tested, but it could help you to understand the filtering of the test run definitions.


TFS Migration Upgrade – “Scale-Out” Reporting Services issues

July 14, 2014

Last Friday I started a long upgrade process to migrate from an old TFS 2005 environment to the latest and greatest: TFS 2013 Update 3 RC. As you know, upgrading from TFS 2005 to TFS 2013 is only possible via an intermediate upgrade to TFS 2010. Both upgrades were full migration upgrades to make use of new hardware. One important note here: make sure you still use Windows Server 2008 R2 to setup the TFS 2010 environment. TFS 2010 is not supported on Windows Server 2012!

image

Anyway, during both migration upgrades, I ended up with a “Reporting” error during the verification process in the upgrade wizard.

image

Having done many upgrades before, I immediately had an idea what went wrong and checked the Scale-Out Deployment configuration in SQL Reporting Services.

image

image

By doing a full migration upgrade (Data Tier + Application Tier), the “old” TFS server (TFS-02) was still joined and blocked the verification process for the Reporting feature in the TFS Upgrade Wizard.

Removing the Server from the UI generates an error, so you need to open up a command prompt to complete this removal process.

image

Use the rskeyMgmt list command and provide the SQL Server instance name if you did not use the default one (MSSQLSERVER). This command will return the guid of the “new” and “old” Report Servers.

image

Copy the “old” guid and use that string to paste it into the rsKeyMgmt remove command.

image

All green now!

image

Would love to see this workaround pop up in the TFS Installation Guide for a TFS Migration upgrade.

All’s well that ends well!

image


Techorama Belgium – ALM and more!

March 30, 2014

For those who lived under a rock the last couple of months, you might not know yet, but there’s a new big international developer conference in Belgium which will take place on May 27 and May 28: Techorama.

Techorama-logo

Together with Gill and Kevin, I decided to roll up my sleeves! Read the full context why we are doing this.

Only 57 days left, so time to have a look at the ALM Track. I’m extremely happy with the speakers who will show up on stage.

May 27, 2014 (Day 1):

May 28, 2014 (Day 2):

You have to agree, this is a great line up and next to the ALM track, there are many other interesting sessions to follow that fit into one of the other tracks: Cloud, Mobile, Web, Languages & Tools and SQL/SharePoint for Devs. Have a look at the full agenda.

So, what’s your reason not to be present at Techorama? What’s missing to get you there? Let us know because over the years we want to make this the best dev conference in Belgium and around!

That’s why we are also promoting Techorama in other countries. Last month we did a Techorama on Tour event in London where Gill and I delivered two technical sessions on Windows 8.1 and Visual Studio Release Management. Other on Tour events are planned but not confirmed yet …

On top of the breakout sessions, Techorama will deliver two inspiring keynotes and during the conference you will have the opportunity to meet your peers and visit our partners.

See you at the first edition of Techorama in Mechelen! All feedback is welcome!


Visual Studio Release Management

January 23, 2014

Today I delivered a session at the VISUG event on Visual Studio Release Management.

I was pretty amazed with the number of people who showed up from the beginning. Usually we have quite a high no-show rate for our User Group sessions, but this time I guess that everybody was present! Thanks for all the people who joined one of our sessions today! The interest in a decent Release Management strategy/solution is increasing quite fast these days.

For a few of my customers, I’m also involved in some POCs to demonstrate the power of the Release Management features in the Visual Studio offering and the feedback is very promising.

My slides of today can be downloaded here and more general info can be found at the Microsoft product page.

Last important remark: using the latest Visual Studio Release Management features (part of the VS 2013 release) doesn’t require you to have TFS 2013. You can point the Release Management Server also to TFS 2010 and TFS 2012.

If you might be interested in an on-site session on this topic for your user group / company, please contact me via this contact form


The evolution of ALM/TFS – pdf available for download

December 3, 2013

A few weeks ago, I started with publishing different parts of an article on the evolution of Application Lifecycle Management.

Part I: Introduction

Part II: Diving into the basics of ALM and how did Microsoft start with an ALM solution?

Part III: Heterogeneous Software Development

Part IV: A fully integrated testing experience with TFS 2010

Part V: TFS 2012 and Continuous Value Delivery

Part VI: TFS 2013 and Visual Studio Online

Part VII: Conclusion

You can now also download the full article in pdf-format (25 pages in total – 2MB).

Happy reading!


Follow

Get every new post delivered to your Inbox.