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

SharePoint 2013 App Testing – First Steps

There is a reason why we can’t use a Sandboxed Solution for our Enhanced Records Management as unfortunately they are not supported in SharePoint Records Centers, we have checked in 2010 and 2013 and it appears to be a long standing bug see https://simpleinnovationassociates.wordpress.com/2013/03/28/sandboxed-solutions-and-sharepointrecords-centres/.

So our Office 365 offering will be a SharePoint App but how do we know even that will work in a SharePoint 2013 Records Center?

In this case we need to establish what is the minimum required for success.  We need to remove anything that will cloud the issue, and in this case that’s any functionality.

A site administrator must be able to install a SharePoint 2013 Application into a SharePoint Site built with the Records Center (OFFILE#1) Site Template.

We don’t care what the SharePoint Application does we just need to know that it will install without error.

So what we need is the simplest possible SharePoint Application, in the simplest possible environment.

A good primer for this can be found in http://www.amazon.co.uk/Microsoft%C2%AE-SharePoint%C2%AE-2013-Development-ebook/dp/B00B8D47F2 and using this we can write a simple SharePoint 2013 Application and deploy it internally via our own application store.

This should be a suitable task for someone to undertake tomorrow.

 

Cheers

Sebastian