Setup for TFS (DR/QA environment)

Question

We are on TFS 2012 currently and planning to upgrade to TFS 2013 soon. I'm trying to better understand what is the best setup for TFS. We currently have multiple teams in the company using it and it is critical as a source control and ALM tool. Nope Visual Studio Online is not an option for us.

Let me know what you guys think specially if someone else has a similar setup.

1) Whether we should have a DR environment for TFS so that if something goes wrong with the Main TFS we can failover? I know we can restore it from the DB backups but that is time consuming specially if the TFS application tier goes down and has to be rebuilt.

2) Should we have a QA/Dev environment so that it can be used to try the upgrade first and if it looks good then done in Prod? It can be used in future to try out features etc. as well.

Answer 1

The ALM Rangers publish a TFS Planning Guide which has a section on how to approach DR with TFS: http://vsarplanningguide.codeplex.com/

You probably should also consider designing a High Availability (HA) TFS deployment. Details of how to do this are in the TFS Installation Guide: http://www.microsoft.com/en-us/download/details.aspx?id=29035

In general though, at the core of TFS is a SQL Server, and all the best practices around HA SQL and DR for SQL apply here. Reconstructing an AT is relatively straightforward, and if you design a HA TFS deployment you will have multiple load-balanced AT's so if one fails the traffic just routes to the healthy AT(s).

Answer 2

In a recent environment I was working in, we had a "QA" TFS server that we could test updates\template changes\plugins, etc. That worked out great for the whole team and I would definitely recommend having a test server if that's an option for you.

I can't recommend what you do for disaster recovery as there are many factors involved that your team needs to decide on. My last team didn't maintain a completely separate rollover environment, but there were nightly snapshots of our TFS servers that were virtualized. We could restore from those snapshots fairly easily. That recovery plan was sufficient for this team based on risk\resources\potential downtime.

I hope that helps.