I want to take a moment to talk about the software development process in two areas that deal with how organizations develop software. In particular, I want to focus briefly on some emerging trends that are supported by Microsoft Team Foundation Server (TFS). In the spirit of covering both existing and emerging trends, I want to start with a concept that I've heard about for years: the daily build.
Six years ago I remember first hearing about how one of the keys to success in a project was having a daily build of your application as you neared the end of your development cycle. I don't mean a daily build as in you open Microsoft Visual Studio 2005 on your desktop and compile the project. I mean having a centralized location in which the files developers check into Visual SourceSafe (VSS) would be picked up and a new instance of the application would be built and submitted for testing. This task isn't trivial. If you've worked with VSS you know that having developers check in their code daily and having that code successfully built is pretty much impossible, especially near the end of a project when you're in crunch mode.
Yet the fact is a daily build is a good way to ensure your code is progressing toward release. Fortunately, one of the add-ons that ships with TFS--Team Foundation Build, which is often referred to as Team Build-- automates the build process. You can install Team Build on a separate server or on the same server on which you installed TFS. When you install Team Build, you also need to install the associated language compilers that you want to use to build your application. Generally speaking, the easiest way to do this is to leverage a copy of Visual Studio 2005 on the Team Build server. Team Build is a scheduling and build environment management engine that relies on the same MSBuild compilers that you use as part of Visual Studio 2005.
The Team Build engine, which interfaces with the source control engine in TFS, lets you automate your build process. When combined with the ability to shelve (and thus not expose) changes that aren't ready for the common build, you have an engine that can, after hours, perform a daily build of your team's application, which you can then test.
However, if Team Build stopped here, there would still be a significant challenge in terms of being able to realistically test the resulting code. But Team Build isn't just a build engine--it's a fully automated build lab. Team Build is fully integrated into the Team System architecture. As such, it reruns static code analysis checks on your application after retrieving and building your application. You can give it the path to your unit test files (created as part of the application development process) and after Team Build runs the analysis engine, Team Build will automatically run these tests. Thus, with a little planning, you can be in a position to not only support a daily build but also have that build provide value beyond just seeing your code compile.
Team Build tracks each step, so after you set up the environment, you can automatically rebuild your application and run unit tests to track progress on open bugs. Team Build can even create new bugs in the task list if, for example, someone checks in a set of source files that "break the build." Let's face it, when you automate this process, no one will want to check in changes that break the build and prevent the automated test runs. (This would be a major faux pas.) Meanwhile, your test team, which is focused on validating build reports and extending unit tests, can also regularly pick up builds for more time-consuming human-interface testing.
Automated builds and tests isn't something new to the developers who work for Microsoft. What is new is that Microsoft has now provided the tools to support this model to the developer community. The result is that after you've set up TFS and installed Team Build, you can move toward a more responsive environment for building applications. The trend across our industry is for faster application development. As part of this trend, one of the emerging processes that application developers are leveraging is the Scrum methodology. Some people refer to Scrum as the "Scrum software development process," but in reality, Scrum isn't a full software development process.
In case you're unfamiliar with Scrum, Scrum is one of the "agile" processes. The name Scrum isn't an acronym but rather a reference to the term as it is used in rugby. The idea is that managing software development is a little like trying to manage the chaos that occurs when two teams face off with locked arms over a small ball. The Scrum process accepts that in the short-term attempting to manage the conflicting priorities and technical challenges that occur on a project is futile.
The Scrum process focuses on the fact that every project can be broken down into a series of smaller steps. Thus, a project's features are broken into subsets. Each subset is given timeframe (measured in days, such as up to 30 days) in which those features must be completed. TFS helps implement Scrum by providing a task list that developers can use to manage the outstanding items in each interim release. In addition, automating the build and testing processes support the shorter development cycles that are common in Scrum.
The Scrum process focuses on managing complexity and developer assignments. It isn't in and of itself a complete software development process. When I hear developers say they're using Scrum as their process, the first thought that consistently crosses my mind is "with what?" Combining Scrum with TFS is a solid step in managing your development process but not the final step.
In my next column, I'll walk you through a couple theoretical projects to
demonstrate how to apply Team System (including TFS) and Scrum. In doing so,
I'll address some of the advantages and risks. In the meantime, if you want
more information about Team Build, go to http://msdn2.microsoft.com/en-
us/library/ms181709(VS.80).aspx . If you want more information about Scrum,
check out these Web sites:
