Microsoft has been talking about Application Lifecycle Management (ALM) at least half a decade, and has had a software solution since 2005. Now, the product is easily approachable by everyone, including the lone developer. But what is the Microsoft ALM solution and why is it useful?
When talking about software development lifecycle and the processes associated with it, many developers immediately think about the waterfall model. In this model, you first design an application, then write and test it, and finally move it to production. However, with today's agile methods, the development process is different and contains frequent repetition of design, coding and testing (but not necessarily in this order).
To write software professionally, one needs a process. Whether this process is an ad-hoc one or a more formal one, a process is still in place. But to create maintainable code that still works years after the initial version requires both a good process and a sound design.
In almost any field today -- software development included -- there is lots of mental pressure: time and budget constraints, limited amount of people and changing workloads. The tendency in such environments is to cut corners. But as a software developer, you already know that this is one of the major reasons why so many software projects fail.
Although there is no miracle cure to solve all software development problems, one can get far by using the right tools and processes that have already been thought out. Microsoft has also noticed this, and in 2005 delivered a product suite called Visual Studio Team System (VSTS). The product helped software development companies focus on what they know best: development.
Fast forward to today, and you will find that VSTS has become Visual Studio 2010 with a server-based product called Team Foundation Server (TFS). This server application is in the core of Microsoft's ALM strategy, and thus worth knowing. TFS matters to both .NET developers and native C++ developers alike. In addition to developers, the product offers many things for testers, graphical designers, architects, project managers, and even customers. TFS can be thought of as being a multi-role product.
What is TFS, Anyway?
Team Foundation Server (TFS) is a server product from Microsoft that allows a development team, among other things, to communicate, share information, file bugs, manage requirements, collect timesheets, and work with source code versions.
Specifically, TFS implements robust version control as core functionality of the server, and on top of that, a multitude of functions. The basic architecture is that a TFS server works along with an SQL Server database (a central store for information) and with one of more client applications. The most notable client application is Microsoft's own Visual Studio development tool, but plug-ins have been written for other development environments as well, including Eclipse. Also, Microsoft's own Expression Blend has built-in integration into TFS. Figure 1 shows the TFS architecture on a high level.
Figure 1. The high-level architecture of Team Foundation Server.
TFS server communicates with the outside world using web services over the HTTP protocol. This means that the solution is not limited to a certain geographic location or a single office. Provided that network connections are available, developers and other people in the team can connect to the server no matter where they are.
In addition to advanced version control - much more robust than Visual SourceSafe ever was - TFS offers integration with other Microsoft products to help for instance in document sharing, team collaboration and reporting. That said, TFS can be integrated with SharePoint and Microsoft Project. It uses SQL Server Reporting Services (SSRS) internally to create reports.
Since TFS is a server product, it does not have an end-user user interface. Instead, all the functions that TFS offers are to be used through a client application, Visual Studio being the premium client at this writing. Using the Team Explorer window (Figure 2) in Visual Studio, a developer (or any other team member) can see how the current projects are going, how many bugs are still open, or how many hours of work is still required to get to the next milestone.
Figure 2. The Team Explorer window is the main integration window for working with TFS.
In addition to the Visual Studio integration, TFS can also be accessed through a web based interface (Figure 3). Previously, this was a separate product, but today, it is automatically installed and enabled when you install TFS version 2010. With the web interface, you can do many of the same things you could with the integrated Team Explorer client inside Microsoft Visual Studio.
Figure 3. Team Foundation Server Web Access provides an easy way to get an insight into a team project.
TFS and Team Work
If version control was everything that TFS offered, then there would not be much to distinguish it from other good version control solutions. However, TFS is much more than just version control, and one of the areas where TFS shows its power is team collaboration.
One of the most important ways TFS helps team reach its goal is to let everyone in the team know the current status of the project. This is done through what are called work items, which can be considered electronic forms of different types. Common work item types are requirements, bugs, tasks and user stories (Figure 4).
Figure 4. Work items provide key functionality within TFS.
By filling these electronic forms properly, everyone in the team can get a list of active bugs, or query all the tasks assigned to them. For the whole team, TFS can estimate the remaining work based on the information in the work items. Work items can be queried through the Team Explorer window which contains standard queries for bugs and tasks, and also work assigned to an individual team member.
By default, work items are filled directly inside Visual Studio or the TFS web interface. Sometimes however, it would be much more convenient to manage work items using Excel. Luckily, TFS contains a ready-made Excel integration that allows you to download work items into an Excel sheet, edit them, and upload back to the server. This works through a handy add-in that can be installed to Excel 2007 and 2010 (Figure 5). There is also integration with Microsoft Project.
Figure 5. Working with dozens of work items is easy with the Excel add-in.
In addition to work items, information can be shared through a SharePoint portal page. In TFS, each team project can be associated with a SharePoint portal page. File based documents can be easily shared within the team, and features such as document versioning and search are immediately available. The SharePoint portal can be launched directly though the Visual Studio Team Explorer plug-in.
Process Models and Automating Builds
In Team Foundation Server, a team project is logical combination of related work items, files under source control and documents shared through a SharePoint portal. A team project is different from a Visual Studio source code project. In fact, a single team project can contain dozens of Visual Studio projects, such as those written with C#. A team project can also be thought of as being a boundary for reporting, security settings and user rights.
A team project is associated with a process model. By default, TFS comes with two process models (see Figure 6), Microsoft's implementations of agile methods (called MSF for Agile) and CMMI (MSF for CMMI). A process model in a team project cannot be changed expect by re-creating the team project (with certain exceptions).
[Part 1, Figure 6 - Process Model.png]
Figure 6. TFS users often start with the MSF for Agile process model.
Among other things, a process model defines the work item types available in the project. For instance, the MSF for Agile process model defines six work item types: bugs, issues, shared steps, tasks, test cases and user stories. Work items can be fully customized, and you can add, modify or delete fields in work items. Then, you can save your modifications to be a process template, which can then be basis for new team projects.
A process model also defines the state transitions of work items. For instance, in certain organizations, a bug fix must be confirmed by another tester before the bug can be marked as fixed. Similarly, a developer might not be the person to mark a bug fixed.
These kinds of rules, should we say development process rules, can be part of a team project process model. Just like you can customize work items to contain those fields you prefer, you can also customize the state transition rules to the way your organization works. In fact, to benefit most from TFS, you should customize the product to the way your organization works. This work can take much longer - days, weeks or even months - than the software installation of TFS.
If process models can take weeks to hone, a feature called build automation saves time in routine tasks. With build automation, a team can define MSBuild based automated operations to fetch latest code from version control, build it, test and even package the application on a set schedule. Continuous integration is available, too.
For instance nightly builds can be created with a simple setup routine. TFS will from then on automatically deliver new versions for testers to test. Unit tests can be run along with the builds, generating status reports that are directly viewable inside Visual Studio or delivered to developers via e-mail. In Visual Studio, build automation is known by the name Builds.
Who Would Benefit From TFS?
The original Visual Studio Team Foundation Server versions were aimed at teams with at least five members: developers, testers, architects and project managers. Today, all of these different types of team roles are still the focus of Microsoft, but TFS scalability has grown in both directions, up and down. That is, TFS 2010 now provides good support starting from the lone developer with multiple hats to large organizations with hundreds of team members. Except maybe for a couple of largest corporations, the technical platform TFS uses can support almost any organization size.
Licensing-wise, Microsoft gives TFS usage rights to everyone who purchases Visual Studio with an MSDN subscription. The TFS server with a license for five users can be also purchased separately for the MSRP of $499. Additional Microsoft-customary Client Access Licenses (CALs) cost the same amount per user. At this price level, TFS should be within the reach of every professional development shop.
Speaking of technology, especially smaller organizations benefit from TFS' modest system requirements. It can run on recent Windows versions, both on workstation operating systems such as Windows 7, or on servers (such as Windows Server 2008). An SQL Server 2008 database or later with Reporting Services is required, but this could be the free version that comes with the TFS license. Alternatively, a regular Standard edition works fine.
TFS uses web services, so TFS requires the Microsoft IIS (Internet Information Services) web server role to function. By default, communication is done using HTTP, but this can be changed to more secure HTTPS by simply modifying IIS settings and installing a proper SSL certificate.
Since TFS uses standard Microsoft technology, it can scale well. With modern hardware, a single TFS server can serve hundreds of users, provided that the SQL database runs on a separate server. Largest installations are in the range of several thousand users per server. In simple setups, the technical installation takes usually less than an hour.
Microsoft Team Foundation Server is a versatile product that solves several different needs software development teams have. TFS integrates version control, requirements management and bug tracking, document sharing and team collaboration, robust reporting, web access, controlled access and even customer insight into the team's work (security settings permitting, of course).
Many of the features in TFS are accessed directly through Visual Studio, meaning that no time is wasted in switching back and forth different tools. Silverlight and WPF developers are happy to learn that Expression Blend can integrate with TFS.
Even though TFS can scale from the smallest to the largest organizations, the system requirements of TFS are easy to fulfill. Installation of the product takes only a short while, but much more time goes to organizational issues. In fact, to best benefit from TFS, organization should crystallize the process it is using, and then fine-tune TFS to suit that need.
A customized TFS quickly becomes an integral part of the organization's software development process. I'm sure you won't be looking back.
This was the first article in a series of articles about Microsoft's ALM solution. The next parts will focus on work items, unit testing, version control and more. Part II continues with version control.
Until next time!