248 Part III: Methodologies and Extensibility
other Team System tools such as Team Foundation Version Control, Work Item Tracking,
and various testing utilities available to developers and testers.
At the completion of the build process, a full report is generated with information about the
build result as well as the general health of the build. This report shows relevant information
about the state of the build, including the following items:
■ The associated number of errors and warnings for each build conﬁ guration with log
ﬁ le links
■ Test run and code coverage results
■ A complete list of changesets that includes the build and who checked it in
■ Work items associated with a build
The bottom line is that Team Build might very well become your new best friend because it
can give you ﬁ nal, stable .MSI ﬁ les that are ready to deploy.
Deploying the Application
Although deployment has minimal support in the initial release of Team System, there are
options to assist with the various deployment-related tasks. Integration with Team Build
and the creation of .MSI ﬁ les are key for helping the development team deploy the solution.
Another is the deployment report that is generated after you test-deploy an application
against a datacenter. This report, similar to a bill of materials, allows you to inventory which
ﬁ les are included for deployment. These tools will assist in planning and implementing your
Closing Down the Current Iteration
As each iteration ends, certain tasks must be accomplished. Part of the “ﬁ t and ﬁ nish” of
software development is to determine which work items are left and whether they can
be completed within the current iteration. If any of the remaining work items cannot be
ﬁ nished, they must be moved into the next (or later) iteration, as determined by the project
priorities. You must also make sure that the ﬁ les in source control are properly labeled so
that you can locate them as needed. Another consideration for future iterations is the need
to possibly branch code as an option if the next iteration forks or takes a weird turn.
Continuing to Track Bugs and Defects
Even after a successful development iteration, build, and deployment, work item tracking
might start tracking user-encountered bugs and defects. During development, primarily the
testers and developers were logging in bugs. Keep in mind that even if an iteration is closed
out for development, work items can still be logged in. Visual Studio 2005 Team System
assists the team in continuing to stabilize the application long after the initial release.
Chapter 10: Wrapping It Up: The Endgame and Deployment 249
When Visual Studio 2005 Team System is used during your project, data is automatically
captured in the data warehouse and used in reports that provide additional insight into
trends and activity within your project. For example, when project tasks are performed, the
data warehouse automatically collects data that enables reports such as the following:
Remaining Work Report
The Remaining Work Report (in a cumulative ﬂ ow diagram form) shows work remaining
measured as scenarios and Quality of Service (QoS) requirements being resolved and closed
in the iteration.
Figure 10-1 Remaining Work Report
The following table explains the various sections of the Remaining Work Report example in
Data Series Line Description
Work Item States Each color band represents the number of work items that have reached
the corresponding state as of the given date.
Chart Height The total height is the total amount of work to be done in the iteration.
If the top line increases, the total work is increasing. Typically, the reason
is that unpla nned work is adding to the total required. That may be
expected if you’ve scheduled a buffer for unplanned work, such as bug
ﬁ xing. (See “Unplanned Work Report,” later in this section.) If the top line
decreases, it means that total work is decreasing, probably because work is
being cut out of the iteration.