Over the last couple of weeks I have dedicated quite some time to knowing Team Foundation Server (from here on out referred to as TFS) and the interaction between it and Visual Studio Team System/Team Explorer. The process has not been without pain, but with pain come great lessons.
So, over the next days I will be posting here what was the success story of installation in both HTTP and then the process to get HTTPS in place too.
But, how about starting to lay down the foundation of what the process is. Let’s explore what it requires.
Before you start with any portion of the installation, make sure you read (not just page through, read!) the installation guide. Understand how your environment is laid out, meaning … are you in a workgroup or domain environment?
Which OS are you planning to use? This is extremely important … keep on reading I will clarify. Are you planning on using SQL Server 2008? Again, important to understand.
Also extremely important to think about (again, do not install until after you have read the installation guide and made some very important decisions) is are you doing single server or “dual” server deployment. The thought of breaking the deployment into layers (Data Tier and Application Tier … will give diagrams of this as I get into the details), will give you flexibility and scalability. But it will require for you to understand what is going on behind the scenes (I will address that in the next posts).
Another part to consider is how your team is composed, mainly what you are looking for is how they will connect to the TFS environment. If they are coming from the Internet, how are you allowing access to the environment. You get the idea.
Now … there are plenty of moving pieces, so it is not only understanding how TFS works and communicates with the Data Tier that will be important. You will have Windows SharePoint Services, IIS, SQL Server and SQL Server Reporting Services. There are other pieces, but let’s focus on some of the “nice to have” information.
OS and IIS
When reading the documentation (and even some blog posts out there), it is not as clear as to what version of the OS to use or architecture (x64 vs. x86). Here is the deal, you will read how some people forced the Application Tier to be on x64. NOT RECOMMENDED!
Here is the skinny … Data Tier can be x64 (of course this means you have then chosen to have a “dual” server setup). The Application Tier needs to be x86 (which means no Windows Server 2008 R2 here). The Build Server (which ideally you will have a separate server) can be x64 and the Build components will work in WOW64.
Also, when making the choice of the OS you are choosing your IIS version too. Meaning, Windows Server 2003 has IIS 6.0 and Windows Server 2008 has IIS 7.0.
Big deal, right? Not quite, it makes a difference in several ways, one of them the process of getting certificates in place and how to enable SSL. Not complicated, yet different.
SQL Server and SQL Server Reporting Services
Choices here are 2005 or 2008, there are differences but maybe the most obvious set will come here in the form of SQL Server Reporting Services. How? SSRS 2008 does not depend on IIS.
That means, get your understanding of how this works and the process to enable SSL and the configuration files SSRS depends on. Become familiar with authentication, also understand differences (specially in Domain based deployments) between using system based service accounts (eg. Network Service) and dedicated domain based service accounts.
Windows SharePoint Services (WSS)
Nothing major here, however make sure you have an understanding of Alternate Access Mappings (AAM), and that you in fact feel comfortable around the way WSS works. Key here is understanding how to deploy, knowing the differences between Basic/Standalone deployment (I have a couple of friends that will twitch at the thought of me mentioning it) and Advanced/Web Front End (WFE) deployment. Here is a link to the installation guide.
That is it for now.
UPDATE: I will be posting my recent implementations of TFS 2010.