Uncategorised

DDDNorth is on again this year, back in it’s more northern base of the Sunderland University on the 24th of October You can submit your session proposal in here

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....

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...

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....

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....