TFS goes Virtual

Hello Once More

As we prepare for doing SharePoint 2013 Apps we decided to look at some of our infrastructure, in many ways the start of a project is the only time you can make these changes.  The middle is too fraught and the end is too risky.

Our TFS server is an aging physical box running TFS and SQL and its done Stirling service.  I have justified this on how ‘important’ it is and how we don’t want to trust this unproven virtualization technology.

However we use virtual boxes here day in day out and they never go wrong, they are easier to manage and we can snapshot them and back them up easily.  Our clients run their production systems on them.  We can easily increase their disk, memory and processors to scale the box as well.  What’s not to like?

We stopped short of buying a virtual machine in the cloud because I wasn’t happy with our source being on someone else’s hardware and because cost wise its still cheaper for us to use our own hardware over three years than rent a VM.

In the end an easy enough process we created a new VM, installed TFS 2012 on it (a big improvement) and took across the existing TFS data stores, fired it up, failed to connect to it, realised that we had it behind a firewall so opened the right ports and, “That’s a bingo!”.

Now I was just about to create a brand new TFS project to hold the SharePoint 2013 solution in when I realised that this would be a very bad idea.  TFS projects should not be specific to solutions or even technologies but teams, or rather code that wants to be shared.  In our case we are going to have a core that is called from both 2010 and 2013 so it will actually belong in the general EDRMS Project.

 

Cheers

 

Sebastian