Using TFS via the internet
My company has been slow to adopt Microsoft Team Foundation Server (TFS) since we already had an established source control process based on a mix of SubVersion and Perforce. But a combination of several recent events over the past couple of months led me to want to dig deeper into TFS. In summary, it’s an impressive product, and I’m glad I did.
The primary TFS adoption barrier for a typical small to medium sized software company, assuming they’re already a predominantly Microsoft shop, will be cost. A quick web search shows prices at $2500 and up. Compared to using file shares, BugZilla, and SubVersion, that’s pretty steep.
However – and this is what hooked us – Microsoft Gold Certified Partners are granted a TFS Workgroup license, along with a certain number of CALs. So, again, if you’re in tight with the Microsoft ecosystem, or if you’re a big Windows software shop, then TFS starts to make sense.
The secondary TFS adoption barrier is its complexity, both in terms of installation and administration. Regarding the former, this step by step guide is indispensible. If you follow it carefully – and read it through once before you start – then installation complexity won’t be an issue.
I needed to go a step further with TFS, though, and expose its source control capabilities securely over the internet for authorized users working remotely. The first step is enabling SSL/TLS access to the TFS server; there’s a walkthrough here for setting that up. I didn’t follow those instructions entirely, though, because
Actually, I didn’t follow those instructions entirely, because the process for moving TFS and all of its dependent components (including SQL and SharePoint) over to requiring TLS is really painful and error prone. Instead, I just setup a server certificate and a port (443) binding in IIS to allow TLS (as in, HTTPS) into the TFS web services.
Then, at the corporate firewall, designate a high port for secure remote TFS access and configure it to forward traffic to 443 on the TFS server. Assuming that integrated Windows authentication is enabled in IIS, that allows external users to attempt to login by entering the password only over an encrypted channel. Equally important, assuming TFS is your source control server, that data travels encrypted as well.
You can always use the same URL to exchange encrypted data with the TFS server from behind the firewall as well, but it’s not enforced.
Anyway, so far, it’s working and I’m glad we migrated.
Hi there,
Great post, hopefully just what I’m looking for but I need to clarify. Are you saying that directly from the Visual Studio interface you can gain access to your source code and check in/out etc. via HTTP over the internet?
We want to use TFS but have this issue where most people are remote but want to share code. I am currently evaluating IBMs Team Concert using Jazz as this has VS addin but would like to stick with TFS if possible.
Thanks, Adam
Yes – exactly. Although, to be clear, I would recommend using HTTPS, so that TFS logon passwords and the source code are encrypted as they transit the net.