Yesterday evening, I joined the Triangle .NET Users Group for their monthly general meeting. The topic du jour was none other than our very own Visual Studio Team System as presented by MSDN Developer Community Champion Geoff Snowman.
Of particular interest to me were the questions asked by the group. Chief among the questions were "What is a typical deployment of Team System?", "What's the distinction and connection between Team System and Team Foundation?", and "Is this software in use yet?" With the help of James Manning, I'll tackle these issues.
Before I address these, however, I'd like to pose a question to any interested parties. Are there any other questions you'd like me to address? I can think of a few, such as "what is a 'pending change'?", "how do I use 'workspaces'?", and "how can I find out about current system status?" If any of these or others interest you, let me know and I'll do what I can to answer them.
First, you may find the system requirements for the December 2004 community technology preview (CTP) helpful.
That being said, our current setup involves a data tier, application tier, build server, and as many clients as you need. The data tier stores the backend database for all of the shared components. The application tier performs multiple functions, including hosting sharepoint team websites, handling of client requests (e.g. version control operations or work item updates), and group permissions. The build server serves as a host for nightly or weekly code drops via the built-in build engine. Finally, the clients are the portal into the system for the architects, developers, testers, managers, and other system users.
Not all of these tiers need be on separate machines, however. In fact, we are considering a single-server install as one of the potential configurations. For more information, see Brian White's recent post.
Let’s try to define the components first. We’ll refer to this diagram taken from one of the presentations on Team System which will be an excellent visual aid. First I want to focus on the bottom box that says "Visual Studio Team Foundation" and shows 7 components. This box represents the server side of things (I kind of wish it actually said "Server" in the box somewhere). While it’s got its own actual components involved (big build can be its own server, there’s both IIS and SQL Server involved, etc.), from the conceptual point of view, it’s all the infrastructure that’s relied on by the actual client SKUs.
Speaking of the client SKUs, let’s move on to those brilliant emerald towers standing on our solid (Team) foundation. Those excellent server-side features are going to need some client-side code to use them, and that’s where we come across the "Team Foundation Client (includes CAL)" box (CAL stands for "Client Access License" for the curious; TLAs are fun!). Part of me really would rather have that box on the bottom of the green stacks with a little cloud or lightning bolt or such to represent the network connection, but you get the point. This Team Foundation Client has a couple of components – it technically includes the command-line interface (all those blogs posts showing h.exe or more recently tf.exe are referring to this box) but what we’re expecting people to use most of the time is the Visual Studio integration. This includes, but is not limited to, the team explorer, version control integration, the work item creation/query interface, and build type creation and kick-off.
Ok, enough about Team Foundation. (Hey, I’m biased! It’s my team!) Let’s see if we can try to sort out the Emerald City. The 3 towers are each a client SKU - you choose one of them as your client. From what I’ve heard, one of these 3 is free if you have a MSDN Universal subscription. If you pick Team Architect, for instance, you get all the designer support, but won’t get 8 boxes that aren’t in that stack (3 in developer, 3 in test, 2 shared between those 2) – Team Test is similarly everything except 7, and Team Developer is everything except 6. If you want everything, never fear! There’s a 4th super-tiger-dragon edition client SKU called Team Suite which is the union of these 3 SKUs. Those who want to learn more may find Lori's post in the Team Foundation blog helpful in further defining the role of Team Foundation.
Yes indeed! Specifically, as a member of the group, I know that Team Foundation is currently being dogfooded by the Team Foundation team. We store our source code, track work items, and even write our code in the pre-release version of Visual Studio 2005. Considering that we've been dogfooding since before the Beta1 milestone, I find this to be one of the most resounding endorsements for the product. We also have industry partners using the CTP for their development.