Background We upgraded our production TFS 2013.4 server to TFS 2015 RTM this week. As opposed to an in-place upgrade we chose to make a few change on the way; so whilst leaving our DBs on our SQL 2012 cluster We moved to a new VM for our AT (to upgrade from Windows 2008R2 to 2012R2) Split the SSRS instance off the AT to a separate VM with a new SSAS server (again to move to 2012R2 and to ease management, getting all the reporting bits in one place) But we do not touch ...

In my last post I discussed how you could wire TCM tests into a Release Management vNext pipeline. The problem with the script I provided, as I noted, was that the deployment was triggered synchronously by the build i.e. the build/release process was: TFS Build Gets the source Compiled the code Run the unit tests Trigger the RM pipeline Wait while the RM pipeline completed RM then Deploys the code Runs the integration tests When RM completed the TFS build completes This process raised a couple of problems ...

Also see Part 2 on how to address gotcha’s in this process When using Release Management there is a good chance you will want to run test suites as part of your automated deployment pipeline. If you are using a vNext PowerShell based pipeline you need a way to trigger the tests via PowerShell as there is no out the box agent to do the job. Step 1 - Install a Test Agent The first step is to make sure that the Visual Studio Test Agent is installed on the box you wish to run the test on. if you don’t already have a MTM Environment in place with a test agent then this can be done by creating a standard environment in Microsoft Test Manager. Remember you only need this environment to include the VM you want to run the test on, unless you want to also gather logs and events from our machines in the system. The complexity is up to you. ...

A few days in and I have solved the few problems I have had Can apply update Security Update for Windows 10 for x64-based Systems (KB3074683) My system tried to apply the KB3074683 patch a couple of time, rolling it back each time. A search of the forums found the answer to this one. As in the forum post I have an Nvidia video card, in fact it caused the problems during the update, so the fix was to delete the UpdatusUser registry entry under HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileList. ...

I have just done an in place upgrade on my Lenovo W520 from Windows 8.1 to Windows 10. Something I had not tried during the beta programme, sticking to running Windows 10 in VMs (mostly on Azure). I have to say the process was pretty smooth. I only hit one issue, and this was the usual NVidia Optimus problems I saw installing Windows 8 and 8.1. This is what happened With Windows 8.1 running mounted the Windows 10 Enterprise ISO ...

If you are using basic PowerShell scripts as opposed to DSC with Release Management there are a few gotcha’s I have found. You cannot pass parameters Lets look at a sample script that we would like to run via Release Manager param ( $param1 ) write-verbose -verbose "Start" write-verbose -verbose "Got var1 \[$var1\]" write-verbose -verbose "Got param1 \[$param1\]" write-verbose -verbose "End" In Release Manager we have the following vNext workflow ...

With the release of Visual Studio 2015 there are some significant changes to Visual Studio and TFS licensing, you can find the details of Brian Harry’s blog. These changes can make a serious change in what you need to purchase for different roles, so it could well be worth a look.

If you are providing a path to a custom test adaptor such as nUnit or Chutzpah for a TFS/VSO vNext build e.g. $(Build.SourcesDirectory)packages, make sure you have no leading whitespace in the data entry form. If you do have a space you will see an error log like this as the adaptor cannot be found as the command line generated is malformed 2015-07-13T16:11:32.8986514Z Executing the powershell script: C:LRMMSServicesMmsTaskAgentProvisionerToolstasksVSTest1.0.16VSTest.ps1 2015-07-13T16:11:33.0727047Z ##\[debug\]Calling Invoke-VSTest for all test assemblies 2015-07-13T16:11:33.0756512Z Working folder: C:a549426d 2015-07-13T16:11:33.0777083Z Executing C:Program Files (x86)Microsoft Visual Studio 12.0Common7IDECommonExtensionsMicrosoftTestWindowvstest.console.exe "C:a549426dUnitTestDemoWebApp.TestsScriptsmycode.tests.js" /TestAdapterPath: C:a549426dUnitTestDemoChutzpah /logger:trx 2015-07-13T16:11:34.3495987Z Microsoft (R) Test Execution Command Line Tool Version 12.0.30723.0 2015-07-13T16:11:34.3505995Z Copyright (c) Microsoft Corporation. All rights reserved. 2015-07-13T16:11:34.3896000Z ##\[error\]Error: The /TestAdapterPath parameter requires a value, which is path of a location containing custom test adapters. Example: /TestAdapterPath:c:MyCustomAdapters 2015-07-13T16:11:36.5808275Z ##\[error\]Error: The test source file "C:a549426dUnitTestDemoChutzpah" provided was not found. 2015-07-13T16:11:37.0004574Z ##\[error\]VSTest Test Run failed with exit code: 1 2015-07-13T16:11:37.0094570Z ##\[warning\]No results found to publish.

I have been using Pester for some PowerShell tests. From the command prompt all is good, but I kept getting the error ‘module cannot be loaded because scripts is disabled on this system’ when I tried to run them via the Visual Studio Test Explorer I found the solution on StackOverflow, I had forgotten that Visual Studio is 32bit, so you need to set the 32bit execution policy. Opening the default PowerShell command prompt and and setting the policy only effect the 64Bit instance. ...

I have been doing some work on vNext Release Management; I managed to waste a good hour today with a stupid error. In vNext process templates you provide a username and password to be used as the Powershell remoting credentials (in the red box below) My Powershell script also took a parameter username, so this was provided as a custom configuration too (the green box). This was the issue. Not unsurprisingly having two parameters with the same name is a problem. You might get away with it if they are the same value (I did on one stage, which caused more confusion), but if they differ (as mine did in my production stage) the last one set wins, which meant my remote Powershell returned the error ...