Updated 20 Oct 2014 – With notes on using an Action for cross domain authentication In my previous post I described how to get a network isolated environment up and running with Release Management, it is all to do with shadow accounts. Well getting it running is one thing, having a useful release process is another. For my test environment I needed to get three things deployed and tested A SQL DB deployed via a DACPAC A WCF web service deployed using MSDeploy A web site deployed using MSDeploy My environment was a four VM network isolated environment running on our TFS Lab Management system. ...

When working with web applications we tend to use MSDeploy for distribution. Our TFS build box, as well as producing a _PublishedWebsite copy of the site, produce the ZIP packaged version we use to deploy to test and production servers via PowerShell or IIS Manager To create this package we add the MSBuild Arguments **/p:CreatePackageOnPublish=True /p:DeployOnBuild=true /p:IsPackaging=True ** This was been working fine, until I upgraded our TFS build system to 2013.2. Any builds queued after this upgrade, that builds MSDeploy packages, gives the error ...

To make sure all our Word documents are consistent we use a Word template that include VSTO action pane. This allow us to insert standard blocks of text, T&C and the like, and also makes sure document revisions and reviews are correctly logged. We have used this for years without any issues, but I recently needed to make some changes to the underlying Word .dotx template and I had to jump through a couple of hoops to get it rebuilding in Visual Studio 2013 for Office 2013 (previously it had been built against Visual Studio 2008 generation tools) ...

TFS 2013.2 got RTM’d last night and is available on MSDN; interestingly Visual Studio 2013.2 is still only an RC, we have to wait for that to RTM. As we had a good proportion of our team at Build 2014 I took the chance to do the upgrade today. It went smoothly, no surprises, though the installation phase (the middle bit after the copy and before the config wizard) took a while. On our build agents, they all seemed to want reboot (or two) at this point, the TFS server did not, but took a good few minutes with no progress bar movement when I assume it was updating libraries. ...

Looking forward to speaking at Techorama in May, great range of speakers and subjects. Hope to see you there, for ticket details see http://www.techorama.be/tickets/

Our testing environments are based on TFS Lab Management, historically we have managed deployment into them manually (or at least via a PowerShell script run manually) or using TFS Build. I thought it time I at least tried to move over to Release Management. The process to install the components of Release Management is fairly straight forward, there are wizards that ask little other than which account to run as Install the deployment server, pointing at a SQL instance Install the management client, pointing at the deployment server Install the deployment agent on each box you wish to deploy to, again pointing it as the deployment server I hit a problem with the third step. Our lab environments are usually network isolated, hence each can potentially be running their own copies of the same domain. This means the connection from the deployment agent to the deployment server is cross domain. We don’t want to setup cross domain trusts as ...

Background The TFS Community Build Extensions provide many activities to enhance your build. One we use a lot is the one for StyleCop to enforce code consistency in projects as part of our check in & build process. In most projects you will not want a single set of StyleCop rules to be applied across the whole solution. Most teams will require a higher level of ‘rule adherence’ for production code as opposed to unit test code. By this I don’t mean the test code is ‘lower quality’, just that rules will differ e.g. we don’t require XML documentation blocks on unit test methods as the unit test method names should be documentation enough. ...

Rik has just done a post on upgrading our SCVMM 2012 instance we use with Lab Management to 2012 R2, a good few gotchas in there as you might expect. Well worth a read

I have just had a guest blog post published on the Microsoft UK Developers site ‘Migrating a TFS TFVC based team project to a Git team project retaining as much source and work item history as possible’. It discusses alternatives to using TFS Integration Platform to migrate source code and associated work items.

A clarification blog post I wrote on what to do if you have multiple SCVMM servers in your network and want to use TFS Lab Management has just been published on the Microsoft Application Lifecycle Management blog. For more information on best practices with TFS Lab Management have a look at the ALM Rangers guide