As a DevProConnections reader, it's a safe bet that you are a Microsoft developer, whether your tool of choice is ASP.NET, Windows Presentation Foundation (WPF), Windows Forms, or another .NET technology. The big question is how you handle application lifecycle management (ALM) for your .NET development projects. How do you handle project, bug defect, work item, automated build, test, and source code management and perhaps also implement agile or Scrum practices? Microsoft's answer to that question is Visual Studio Team Foundation Server (TFS) 2010.
TFS is a comprehensive suite of services that allows developers and teams to manage just about every aspect of the application lifecycle. In its third major version, TFS 2010 represents a major upgrade over its 2008 and 2005 predecessors. Here I'll provide a brief overview of TFS's major facets, with the goal of giving you a 50,000-foot view of what TFS is and how it integrates with the Microsoft stack. After reading this article, if you want to learn more about TFS's many features, your best bet is to visit TFS's online home.
Visual Studio Integration
TFS has two major advantages for the Visual Studio developer: It's an all-encompassing environment that covers every major aspect of the application lifecycle, and it's tightly integrated into the Visual Studio IDE and also integrated with other Microsoft tools (e.g., Microsoft SharePoint, Office, Expression). The features discussed in this section refer to TFS's client features and, specifically, Visual Studio's ability to assimilate those features. These abilities change depending on which Visual Studio version (Professional, Premium, or Ultimate) your team uses. TFS's core competency has always been with source-code control, and regardless of which Visual Studio version you have, you have access to source-code control. Source-code control, however, represents only a fraction of what TFS can do, and for that reason, the real entry point for TFS is Visual Studio Premium.
For a developer working in Visual Studio, the first step to working with TFS is to connect to a TFS instance. You connect to a TFS instance by selecting the Connect to Team Foundation Server option from the Team Menu. You will then see a dialog like the one in Figure 1.
Once you connect to a TFS instance, you then have the option of selecting a project collection and then a team project under that collection. Every TFS instance must have one project collection; this is the default collection. Under each collection are one or more team projects. A team project can consist of one or more Visual Studio solutions. How your collections and projects are organized is up to you, depending on your specific situation.
After you have connected to a TFS instance, you can interact with TFS, as shown in Figure 2. As you would do with other source-code control providers, with TFS you will map to a local drive and work with your local copy of source code. Periodically, you will check in your changes to TFS. Depending on your environment, the check-ins can also be associated with work items.
In an agile environment and with the TFS agile templates, you can define user stories and tasks. These user stories and tasks will have associated estimated story points. When you check in your changes, you can associate such check-ins with those work items. This is the basis for how project metrics are captured, which, in turn, provides the data for reports such as a burn-down chart that facilitates determining team velocity. (For more information about TFS and agile, see "Agile/Scrum Development with Visual Studio 2010 TFS.)
As mentioned, TFS's core functionality is that of a source-code control provider. The typical work flow is:
- Check out a file.
- Make modifications.
- Create/modify tests and ensure test passage.
- Check in files (with associated work items).
From Visual Studio, you can access the source code (both the trunk and any branches that have been created). In addition, you can access items such as work items, test cases, build definitions, project documents, and reports. Just about all your interaction with TFS will be from within the Team Explorer, as shown in Figure 3, which is similar in look and feel to Visual Studio's Solution Explorer.
Visual Studio is a great environment for writing code and developing applications. But how can you manage projects within it? And more specifically, how can you manage work items, collaboration, metrics, and reporting in a way that introduces the least amount of friction to the team? Ideally, you would have a tool that integrates into Visual Studio-and TFS meets this need. TFS provides process guidance for every step of the application development process, from planning to delivery.
One of the biggest challenges with project management involves requirements, work item definition, and tracking. These items are essential for the proper capture of metrics so that you can track what work has been accomplished, which, in turn, provides an indication of the work left to be accomplished. Figure 4 shows the relationship among work items. Work items allow you to track every unit of work that facilitates driving your project forward toward delivery. These tracked work items allow you to generate metrics that give a measure of team velocity.
For reporting, TFS uses a SharePoint portal that enhances team communication, document tracking, and collaboration and provides dashboard-style reporting (shown in Figure 5). The reports show project progress and velocity. It is very easy to create custom reports. Reports are available in various formats: Microsoft Excel, Visual Studio, web, SQL Server Reporting Services, and SharePoint.
The bulk of what developers do is write code, and TFS does a great job of managing solution/project artifacts with its source-code control (SCC) capabilities. Figure 6 shows the check-in UI that you use to check in your source-code modifications. Through this interface, you can provide a comment and, most importantly, associate your check-in with work items. This is the basis for the capture of metrics that support TFS's extensive reporting capabilities.
Two additional features that deserve special attention are shelving and gated check-ins.
- Shelving allows you to place your modifications in a shared area so that another team member can review your work, without requiring you to check in your changes to the SCC repository.
- Gated check-in prevents a developer from checking in a change that would "break the build."
Another feature, which is often overlooked, is the fact that TFS integrates with database management. Through the database project type, TFS can deploy and run unit tests to verify whether your database is in conformity with the requirements.
Finally, it's important to note that TFS is not just for Microsoft .NET code. One of TFS's key features is Team Explorer Everywhere (TEE), a plug-in that allows Java developers to access TFS from an Eclipse-based IDE.
The hallmark of any successful project is directly correlated to the extent it embraces testing. Through its Test Manager feature, TFS supports several types of automated and manual testing:
- Unit testing: the most granular level of testing, to ensure that code complies with the spec. You perform unit testing through TFS's unit test runner, shown in Figure 7.
- Web testing: automated testing of web apps through HTTP request and response.
- Coded UI testing: for rich UI apps such as WinForms and WPF.
- Load/stress testing: takes unit, web, and coded UI tests and wraps performance counters around them.
TFS also includes Test Professional, a tool for QA and test teams that lets you manage test plans, test suites, and test cases. This test management capability allows you to track tests against requirements and to verify whether bugs have been fixed.
You have built and tested your code. The question is, are your changes synced with changes made by other team members? You may be familiar with the term continuous integration (CI). The idea behind CI is that every check-in kicks off a process that:
- compiles and builds the artifacts (solutions and projects) in the TFS team project
- deploys the database, if a database project is present
- runs tests
If your team project compiles and builds and your tests pass, you have a good build. If your team project does not build and compile, you have what is known as a "broken build." If your team project compiles and builds, but one or more tests fail, you have what is known as an "unstable build"-a different type of broken build.
TFS lets you configure automated builds triggered by check-ins, through the build configuration dialog shown in Figure 8. This dialog offers multiple choices for setting up a build trigger:
- Manual: Check-ins do not trigger a new build.
- Continuous Integration: A build is triggered for each check-in.
- Rolling builds: Check-ins are accumulated until the prior build finishes.
- Gated Check-in: Check-ins are accepted only if the submitted changes merge and build successfully.
- Schedule: Builds are scheduled and queued for specific days and times.
The final facet of TFS that I'll cover is software and data modeling. TFS's modeling features allow you to analyze requirements with use-case and sequence diagrams. You can also define acceptance tests. For UI prototyping and data modeling, you can take advantage of TFS's integration with Microsoft tools: Microsoft Expression's SketchFlow, to prepare storyboards and wireframes for UI prototypes, and Microsoft Visio, to prepare entity-relationship models (ERMs), as shown in Figure 9. (For more information about using SketchFlow for UI prototyping, see "Expression Blend's SketchFlow Syncs Up Silverlight Designers and Developers." )
TFS + Team Commitment = Success
In this compact overview, I've shown that TFS is an expansive product that integrates seamlessly with Visual Studio and other Microsoft tools. Although TFS manages every aspect of the application development lifecycle, you don't need to implement every feature to reap TFS's team-development benefits. For many teams, TFS's source-code control, testing, and build features are sufficient. TFS is also an excellent tool to facilitate working with agile and Scrum methodologies, through the workflow templates that Microsoft provides, as explained by my colleague Brian Minisi in his article "Agile/Scrum Development with Visual Studio 2010 TFS."
If you are contemplating implementing TFS, the best advice I can give is to start with a small project as part of a pilot implementation. Whenever you introduce tools that go to the heart of how developers carry out their tasks, you want to take great care in making sure your development team is on board. Bottom line: Tools are not panaceas. The phrase to remember is People, Process, and Tools, in that order. To successfully adopt ALM principles in your development shop, first you need a team of people who are committed to that effort. With dedicated and committed people, you can then adopt a process. Only then can a tool such as TFS improve your software development efforts.