Hands on with Microsoft Team System
Is integration sometimes tighter than you’d like?
Historically, Microsoft has shown little interest in application lifecycle tools. The company was content to make Visual Studio extensible, and have third-parties fill the gap between a single-developer IDE and a manageable software development process.
The one concession to team development was Visual SourceSafe, a bundled source code management system which integrates nicely with Visual Studio but was never engineered to work properly across a wide area network, and which earned a reputation for occasionally corrupting its database.
Then in 2003 IBM acquired Rational Software Corp, which at the time was a key Microsoft partner, offering Rational Rose modelling for Visual Studio as well as a full suite of lifecycle tools underpinned by the RUP (Rational Unified Process). For Microsoft it seems to have been a wake-up call. If Visual Studio was to compete against IBM’s WebSphere tools in enterprise development, the company had to improve its application lifecycle offering.
Three years on, the outcome is Visual Studio Team System. It is a weighty suite of tools, covering the software lifecycle from initial design through to final build. Features include system and application design; source configuration management; code analysis and profiling; web and load testing; unit testing; bug tracking; and build management. On top of all this, Team System creates project portal sites, enabling team members to collaborate and to monitor progress.
It is a lot to take in. Perhaps the best place to start is with the architecture of the suite itself. The heart of it is called Team Foundation and has three tiers:
- The data tier runs on SQL Server 2005 and stores application data including source code, test results, bug reports and other work items. This can be on the same machine as the application tier, or on a separate server.
- The application tier is a set of web-based applications and services running on ASP.NET and Windows Sharepoint Services.
- The client tier is primarily a module within Visual Studio 2005 called Team Explorer. In addition some Office applications can access the application tier directly.
Most of the other elements in Team System are extensions to Visual Studio. Some of these make sense as individual tools with or without Team Foundation, but in most cases there is tight integration.
“Tight integration” truly characterises Team System. That is a mixed blessing. Microsoft is a company which supposedly evangelises the benefits of loosely coupled web services, yet it has come up with a system replete with dependencies. Team Foundation installation has excellent documentation, which is just as well bearing in mind the precise combination of service packs and hotfixes required for success. The basic dependencies are Windows Server 2003 with Internet Information Services and Sharepoint Services, SQL Server 2005 and .NET Framework 2.0. You also need Active Directory for user management. Installing directly onto a domain controller is possible but not recommended. Setup overall is non-trivial, but in our experience works smoothly if you follow the documented process. Even so, the intricate network of dependencies is a long-term worry.
Sticking an extra server or two onto the network for Team System is no problem in the enterprise, but it is a significant barrier for small development teams. Microsoft has come up with a system that is fine for scaling up, but less good for scaling down. There are also licensing implications. Licensing is on a Server/CAL (Client Access License) model, and is sufficiently complex to merit its own white paper. In reality, enterprise users will likely have blanket licensing agreements with Microsoft that make this easy. That was certainly the reaction of early adopters EDS when I asked about the cost. “We’ve got a large volume licensing agreement with Microsoft. It is very simple for us. It only complicates for us if we’re trying to extend our services out to customers,” explained lead technologist Etienne Tremblay. Contrast that with independent contractor Sean Hederman, who says Team System is “way, way, way too expensive.”
Source code management
Team System does much more than source code configuration management, but nevertheless this is arguably the core feature. How does it rate against the likes of Perforce or Subversion? Leaving aside the intricacies of installation, pretty well. Unlike Visual SourceSafe, Team System works well across a WAN, particularly since you can install a proxy server that caches file downloads, greatly boosting performance. The feature set is comprehensive. Team Foundation is changeset-oriented, where a changeset is a group of changed files. As you work, such files are listed as pending changes. Checking in a changeset is a transaction that succeeds completely or not at all, a feature called atomic commits. Shared check out is allowed, allowing several developers to work on the same code, unless you set a policy to prevent it. A merge engine deals with multiple edits to the same file. In Team System, Get Latest Version is correctly a separate operation from Check out; you can check out for edit without getting the latest version if you want.
Check-in can be constrained by policy, such as requiring that code analysis is run before check-in. This is an interesting feature, but spoilt by limitations in the constraints you can create, and the fact that policies are set in Visual Studio rather than centrally managed. For example, you cannot specify that a certain percentage of code is covered by unit tests, or set a maximum number of code analysis warnings per lines of code. In any event, the developer can always override the policy and check-in anyway, which is probably the right approach and avoids frustration.
Team System also has an alerting system, and you can have it generate emails whenever anything is checked in.
Another key aspect is branching and merging. Like Subversion and Perforce, Team System supports cheap copies. This means that when you copy a file to a new branch, the data is not duplicated on the server, but references the same file as the original until you make a change, thus making the repository more efficient.
A distinctive feature is called shelving. A shelveset is like a changeset, except that it is not fully checked in to a workspace. You can share shelvesets with other users. The documentation suggests several uses for shelvesets, including storing changes ready for code review by others, and backing up or sharing work in progress. Shelvesets are not themselves versioned, but can be unshelved and then checked in.
Best of all, Team Foundation has a command-line interface, and a few operations are available only from the command line. One obvious use is to create scripted source control operations. Microsoft’s command-line client runs only on Windows, but teamprise has a Java client that runs cross-platform, as well as an Eclipse plug-in.
The work item: key to Team System
Alongside maintaining your source, a key part of Team System is work items. Work items may be bug reports, tasks, requirements, risks, or almost anything that needs to be tracked and as part of a project. Work items can be assigned to users and linked to other Team System elements such as source files or changesets. They are also workflow items, with states, transitions, and reasons for transition. For example, a bug might move from Active to Closed with a reason of Fixed. Transitions can be set to trigger automatically in response to actions. Work items can also trigger alerts when changed. Project administrators can define custom work item types in XML and import them into the system. Since work items are stored in SQL Server, you can query them and report against them, and they also turn up in the project portal site (see screenshot). Work items are the building blocks for many other Team System features.
One such feature is the process template. A process template provides a set of work item types and their workflow, defining the way work is done. Templates also include project member roles, predefined reports, and extensive documentation, all of which show up in the project portal site. Two process templates are supplied, each representing a different development methodology. The MSF (Microsoft Solution Framework) for Agile Development is aimed at small, rapidly delivered projects, while MSF for CMMI (Capability Maturity Model Integration) is aimed at ensuring quality in large projects and teams. Third parties have provided additional templates such as Scrum, and all templates can be extended and customized by users.
Roles and packaging
Microsoft packages Team System as three different role-based products. Each product is really a version of Visual Studio, and Team Foundation Server comes separately whichever you choose. Team System for Architects comes with the Distributed System Designers, modelling tools that combine application architecture with deployment scenarios making a powerful “design for deployment” tool.
Team System for Developers has analysis tools and unit tests (see this earlier Reg Developer article), while Team System for Testers has web tests and load tests in addition to unit tests, along with the ability to manage test suites, though the Team System Load Agent for distributed load testing is an expensive extra.
The role-based packaging is unpopular with developers, because the mix of features is somewhat arbitrary, and is not always a good fit with the work individuals actually carry out. The existence of a Tester role is somewhat at odds with test-driven development philosophy. According to Microsoft, Team System was conceived as a whole, and the only reason for the existence of role-based editions is to reduce the price. If you can, it is better to follow the example of EDS and equip developers with Team Suite, which includes all of the roles.
Evaluating Team System
There is a huge amount in Team System, only a fraction of which is covered here. You can find a handy feature list here. However, Team System is more than the sum of its parts. The achievement is most visible in the project portal site, the central location where all project participants can monitor project progress. Integration with Visual Studio and with work items means that the portal updates automatically. Microsoft has also come up with a decent source code management system, a strong set of static analysis and testing tools, and useful extras ranging from the distributed system designers through to load testing and build management. This is version one and there are annoyances, omissions and limitations, some of which are plugged by third-party tools, but it is a huge step forward from plain Visual Studio and SourceSafe.
That said, there are a couple of fundamental problems with Team System. The first is that its heft and expense is a barrier for small teams, which account for a large proportion of software developers. They will be inclined to use open source tools like Subversion for code management and NUnit for unit testing; and Microsoft may find it hard to get them back even if the team grows.
The second issue is that Team System is so closely hooked into Visual Studio and Windows Server applications that it is not suitable for more diverse environments. Even EDS, early adopters of Team System, recognise this. “We’re incorporating Team System into our tool landscape, but it’s not displacing what’s currently there,” said Chief Technologist Aaron Kowall. “Its benefit is around .NET development. We do a lot of Java development within EDS, and we are not looking at Team Foundation Server to support that. We use Borland’s Star Team.”
Another way of looking at this is the problem Team System poses for third-parties. The system is highly extensible, but for full participation a third-party tool has to understand and generate work items as well as integrating with Visual Studio. This is a problem for tools that have their own repositories. Since Team System is arriving relatively late in the day, it poses a migration and integration challenge for organizations already using alternative tools.
What’s it going to cost?
The starting point is around £3,670 for Team Edition for Software Developers with an MSDN subscription, includes a CAL, as well as the workgroup edition of Team Foundation Server supporting up to 5 users. The full Team Foundation Server is £1,878, while the Team Suite version of Visual Studio with MSDN is £7341. More details are here. To work out how Team System licensing interacts with volume licensing, Windows Server licensing, and how to license non-developers using the system, consult the white paper here.