Team System is the name given to a family of products that Microsoft released in conjunction with Visual Studio 2005. This family of products is an automation suite targeted at software developers. As a group, software developers suffer from a common malady. To paraphrase an old saying, "Developers sell automation, they don't use it." Team System isn't oriented around writing code but rather is oriented around providing tools to automate the process of creating an application. This process, called software configuration management, goes beyond just having a good source control system, which is why Microsoft is introducing a suite of related tools under the banner of Team System.
I want to start my discussion about Team System by bringing to light Microsoft's challenge: recouping its investment in developing Team System. Historically, Microsoft has kept prices low by developing OSs and office software that could be sold to a very large market. However, the Team System tools aren't going to be purchased by the average consumer or business user. Similar to Visual Studio (VS), Team System targets what is still a relatively small market.
Thus Microsoft needs to try to recover its development cost from the developer community. However, there are many developers who build products only as a hobby--and the Express Editions of Visual Studio 2005 already target this portion of the developer community. The fact is that the market for Team Services is currently only slightly larger than the market for those people who purchased a Microsoft Developer Network (MSDN) Universal Subscription. Up until this year, most of these subscribers were fulltime developers and not casual developers.
The MSDN Universal Subscription historically provided every tool a developer might need, including Microsoft SQL Server, Windows OSs, Microsoft Office, and Microsoft BizTalk Server. Each tool came with a limited license for development purposes. For a fulltime developer, this subscription was a cost-effective way to keep the tools they need at hand.
Microsoft realized that if it were to add Team Services to the MSDN Universal Subscription, the cost of this subscription would have to increase dramatically. So, Microsoft replaced the MSDN Universal Subscription with a set of related MSDN products, each targeting a different subset of Team System products. Developers will probably pay about the same for one of these subsets as they paid for the MSDN Universal Subscription. However, with this new product setup, developers who were accustomed to having all the Microsoft tools in one package will instead be limited to a subset of all the tools. This hasn't been the most popular change, and Microsoft is working hard to resolve the pricing issues. Microsoft is still accepting feedback, as evidenced by Rick LaPlante's WebLog (http://blogs.msdn.com/rickla/default.aspx), which I encourage you to participate in.
As Rick's WebLog demonstrates, at the heart of the debate is the Team Foundation Server (TFS). For most people, TFS is the replacement for Visual SourceSafe (VSS). Although Microsoft is releasing an updated version of VSS, which will continue to be available on MSDN, TFS is VSS's successor. However, as I noted previously, Team System is about automating software configuration management. Thus, TFS isn't just a replacement for VSS. TFS goes beyond just providing source control; it also provides a central repository for the assignment of work items. You'll even be able to store and report on your team's work items and directly report on and leverage automated test results. The key is that TFS is at the heart of automating the software development process. There are two excellent sources of information about this process. The first is Microsoft's official Team Development Web site at http://lab.msdn.microsoft.com/teamsystem/teamcenters/team/default.aspx. The second is Rob Caron's Blog at http://blogs.msdn.com/robcaron. Rob is an impressive blogger. His frequent posts target issues relevant to the development community. He's committed to getting the right answers to questions about how to start to use Team System.
TFS will be a great product, so now is the time to start testing the beta and getting a feel for what it has to offer. However, before you take on the challenge of starting to set up TFS, read the information in the Visual Studio 2005 Team Foundation Server Beta 2 Installation Guide. You can download the latest version of this guide at http://www.microsoft.com/downloads/details.aspx?familyid=e54bf6ff-026b-43a4- ade4-a690388f310e&displaylang=en. If you're going to use virtual machines for this beta product, you'll also want to review a runtime configuration located in Buck Hodges' blog at http://blogs.msdn.com/buckh/archive/2005/04/19/409886.aspx.
As developers, we've all seen how the introduction of automated processes tends to trigger a period during which people are trying to catch up with how the tools have changed their jobs. In the end, we're no different from other professionals on whom automation is imposed. There will be a period during which we struggle with the new features of our now automated process.
However, the distillation of the MSDN Universal Subscription into subsets of Team System products can actually work to our advantage. There are too many techniques, technologies, and products for one developer to master everything. In my next column, I'll discuss the various subsets of Team System products, then present my view on how to decide which one to choose when you can pick only one.
