Working with the BuildStep Task

One of the new convenience tasks added to Team Foundation Build 2008 is the BuildStep task.  This task allows you to add custom messages to the build reports created when you run a team build.  For example, you may want to display the message "Publishing web site" while your build script is updating some files on a web site.  Having the ability to "see" what your build script is currently executing is not only useful but can also be a great debugging tool (the messages are also logged as well as being displayed).

The BuildStep task accepts the following parameters:

• TeamFoundationServerUrl - specifies the Team Foundation Server URL.  For example: $(TeamFoundationServerUrl).
• BuildUri - specifies the build URI - for example: $(BuildUri).
• Name - specifies the name of the build step added by this task.  NOTE: this parameter appears to be optional - i.e. it works just fine with or without a Name being specified.
• Message - specifies the text of the message to be displayed within the build report.
• Id - specifies the optional input/output parameter. If specified, this is the ID of the build step that is updated. If not specified, a new build step is created.
• Status - specifies the status for the build step.  For example, Succeeded, Failed, or Stopped.

There are several variations in how you can implement the BuildStep task.  I've listed two of the more common scenarios below:

Simplest Scenario - Add a Message
The simplest scenario involves just adding a build step message to the build report with a status of "Succeeded".  To do this, use the following pattern (note: the target "PackageBinaries" is used for illustration purposes only - the task can be utilized from within any target you wish):

<Target Name="PackageBinaries">
  <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
             BuildUri="$(BuildUri)"
             Message="Publishing web site"
             Status="Succeeded" />
</Target>

This will display the text "Publishing web site" in the build report:

You can leave off the Status parameter, however, the icon displayed next to the build step will not indicate a completed task.  If you leave the Status parameter in, then the status icon will indicate a completed task as soon as the build step is displayed, even if the task has not yet completed.  To present a more accurate indication of what's currently executing, use the next template.

Complete Scenario - Display Actual Status
Ideally, you would want to display the icon that indicates a build step is executing until the step has completed and then change the icon (and optionally the message) to a "completed" status.  To do this, use the following pattern:

<Target Name="PackageBinaries">
  <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
             BuildUri="$(BuildUri)"
             Message="Publishing web site...">
    <Output TaskParameter="Id" PropertyName="MyBuildStepId" />
  </BuildStep>

  <!-- Long running task goes here... -->
  <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
             BuildUri="$(BuildUri)"
             Id="$(MyBuildStepId)"
             Message="Web site published"
             Status="Succeeded" />
</Target>

In this example, we're tracking the ID of the newly created build step (in the property MyBuildStepId) so we can use it in a subsequent BuildStep task to set the status icon to "Succeeded" and update the build report text.

NOTE: You can leave the Message parameter off in the second BuildStep task in the above example if you want to leave the original message text unchanged.

Although this is a new addition to the TFS 2008 release, you can get similar functionality for TFS 2005 by using a custom build task.  One example of such a custom build task is available here.

10 Reasons for TFS with Small Teams

Over the past year or two I've read and heard, on multiple occasions, comments along the lines of "our team is not big enough to justify Team Foundation Server" or "we don't have the need for TFS". Contrary to these perceptions, Team Foundation Server can provide a lot of benefits - even for small development teams.

Here is a list of ten reasons for using TFS with small development teams (in no particular order):

1. Version Control - no matter how small or big your development team and/or project is, everyone eventually loses source code for one reason or another (e.g. power/network outage, hard drive crash, human error, etc.). Along with the ability to backup source code (and other project "artifacts") a good version control system (like the one built into TFS) allows you to version your source code, apply labels, and perform branching/merging operations. The version control system built into TFS utilizes Microsoft SQL Server as its data store which allows for easy backup and restore operations.
   
2. Automated Builds - a lot of time is spent on the actual development of a product. However, unless you "package" your product for deployment/publishing, then you're only half way there. TFS allows you to create automated build scripts that will build the latest version of your source code, in a clean environment, and (optionally) perform various tests against the source code, build installation packages, deploy files (e.g. web sites, MSI packages, etc.), publish build reports, etc.
   
   With TFS 2008 you also have the option to setup Continuous Integration with the click of a button or schedule a specific build type to run at a pre-designated time (e.g. "nightly" build). Frequently running an automated build script provides a certain amount of assurance that you can deploy/ship your product with limited notice.
   
3. Work Items - anyone that's ever been involved in the software development process (no matter the size) has created various types of lists. For example, a list of requirements, a list of defects, a "wish" list, etc. There are at least two down-sides to these lists: lack of tracking and lack of workflow.
   
   TFS allows you to create Work Items which, out of the box, are things like Bugs, Tasks, Scenarios, Risks, etc.. You can also modify existing work item types and/or create your own (e.g. to more closely match your development practices). These work item types also have the ability to define a workflow so that the work item can move from one state to another in a controlled fashion.
   
4. Documentation Management - regardless of the size of your project or the type of software development methodology you're using, you will no doubt create some documentation along the way (even if it's as simple as installation instructions). TFS utilizes Microsoft Office SharePoint Services (MOSS) to store and manage documents related to your project. In fact, the Team Explorer Client that integrates with Visual Studio gives you direct access to your SharePoint documents directly from within Visual Studio.
   
5. Unit Test Integration - although you can create and run unit tests in Visual Studio without the use of TFS, by automating your unit tests within a TFS-based build, you can track the progress of unit tests over time and publish each test run to TFS (e.g. so that it can be viewed within various reports and/or the TFS SharePoint site).
   
6. Code Coverage Integration - like unit tests, you can get code coverage manually within Visual Studio. However, by including code coverage in your TFS-based builds, you can track code coverage over time and view the results within various reports and/or the SharePoint portal.
   
7. Integrated (Static) Code Analysis - again, like unit tests, you can run static code analysis manually from within Visual Studio (e.g. via FxCop). However, having the ability to enforce code analysis rules at the time your source code is checked in and/or built, you can add another level of quality control to your project.
   
8. Distributed Development - you may end up on a project, even with small teams, where the team is physically distributed - e.g.. home vs. work, work vs. another country, etc. This physical separation can introduce many challenges for developers (e.g. source code concurrency/consistency, updating documentation, modifying work items, performance issues, etc.). TFS was built from the ground up with this challenge in mind. You may have TFS installed at your company's office but can still connect to it using the Team Explorer client from your home (assuming the TFS server is accessible via the Internet or VPN).
   
9. Overall Integration - all of the features listed above can be cobbled together using other Microsoft, open source, or 3rdparty products. However, what this type of environment would lack is the overall integration provided with TFS. For example, you could use NUnit for running unit tests and possibly utilize CruiseControl.NET to implement your build process. However, how would you publish the unit test results to a web site for later review? How easy would it be to provide a history of those results?
   
10. Cost (sort of) - one of the more common reasons you hear when justifying the use of open source software is the price - i.e: free. However, "free" doesn't always come without cost. Without the integration provided by TFS, you will no doubt be spending a good amount of time "wiring" various technologies together to gain similar functionality.
    
    With TFS, you spend a lot less time on integration issues and more time concentrating on developing and increasing the overall quality of your product. If the features listed above can save your several hours of manual effort a week or possibly reduce the defect rates of delivered products, what's that worth?
    
    There are basically four Team Foundation Server products:
    
• Team Foundation Server Trial Edition - this is a fully functional 90-day trial edition. If you want to give TFS a try, you can download the trial edition here.
• Team Foundation Server Retail Edition - this is the "full" version of TFS with a price starting around $2,000 (and going up, depending on your specific needs).
• Team Foundaiton Server Volume License Edition - this is basically the same as the Retail Edition, only it's obtained differently.
• Team Foundation Server Workgroup Edition - this is a 5-user version of Team Foundation Server with the same functionality of the full version. This version is included with the "Team System" editions of the MSDN Premium subscription. So, if you (or your company) already has one of the "Team System" MSDN Premium subscriptions, then you already have this edition - so why not use it?

For more details about the different versions of Team Foundation Server, check out this post.

This list only scratches the surface of what's available within Team Foundation Server and the benefits it can provide to teams of all sizes. As TFS matures and approaches the next release ("Rosario") the features will only improve and the benefits will increase.

Displaying Quality Indicators

A few days ago, I put an article together for Paul Hacker's TFSTimes.  The article, Displaying Quality Indicators on your TFS SharePoint Site, discusses usefulness of the Quality Indicators report that ships with Team Foundation Server and how to add it to your project's SharePoint Site.  The article also describes how to modify your build types to automatically run all unit tests as well as how to include code coverage statistics with your build.

You can read the article on-line here until the next issue is posted.  The archived PDF version is available here.

Omaha Team System User Group

The first Omaha Team System User Group meeting is, as they say, history!  The feature presentation, What's New in VSTS 2008, was presented by Bill Maurer (a Microsoft Developer Technology Specialist).  He also covered some of the new features coming in "Rosario".  The presentation was very interesting and information and was well received.

Our first meeting was held January 22nd and was sponsored by Farm Credit Services of America.  It was very well attended with 75 attendees.  Our next meeting has not yet been scheduled but I am looking forward to working with fellow Team System enthusiasts in the Omaha area.

If you happen to be in the Omaha area and have any suggestions for user group topics, please visit the OTSUG site and drop send me a message.

Links:

• Presentation PowerPoint slides
• Omaha Team System User Group

TFS/MSBuild Sidekicks Updates

The Attrice corporation has been hard at work updating their set of Sidekick Utilities for VSTS/TFS 2008 (I know I'm excited!).  I've been using these tools for quite some time now and have been waiting for the upgrade ever since we updated to VSTS 2008 a month or so ago.

First in line are the Team Foundation Sidekicks which includes the following features:

• History Sidekick - provides various functionality for viewing the history of items within version control.
• Status Sidekick - (I use this one a lot) - allows you to search and view pending changes for items based on user name, project name, and/or a given date range.  Based on the current status of an item you have the option to undo a pending change or lock.
• Workspace Sidekick - provides functionality for managing TFS workspaces - e.g. deleting, updating, or copying.
• Labels Sidekick - provides functionality for managing labels within version control.
• Shelveset Sidekick - provider functionality for managing shelvesets.
• Code Review Sidekick - allows you to select and compare changesets and save the results for later use.  This also shows up in the context menu for the source code explorer (SCE) window in Visual Studio.  I haven't had a chance to use this Sidekick yet but it looks like a nice time saver.
• Visual Studio Search Items Add-in - by default this option is turned off because there is now search capabilities built into VSTS 2008.  However, if you're still using VSTS 2005, this can be a real time saver (turn it on via Tools->Options->Team Foundation Sidekicks).
• Visual Studio Build Type Add-in - this used to be a separate add-in but is now part of the TFS Sidekicks package and is one of my favorite features.  This add-in gives you the ability to right-click on a build type within the Team Explorer pane (in Visual Studio) and select "Check Out for Edit..." which will then check out the build type's TFSBuild.proj file (or whatever it may be named) and open it for editing.  Accordingly, there are also menu options for checking the changes back in or rolling the changes back.

If you spend any time at all administrating a TFS server or editing build types then these tools are a MUST HAVE.  Even if you only use them once in a great while, they're still a huge time saver over the command-line utilities that ship with TFS - besides, they're free!

They also offer a product called Microsoft Build Sidekick which gives you various editors/views for your MSBuild scripts.  One of the coolest features of this tool is the "Targets Diagram" which gives you a graphical view (similar to something you might see in Microsoft Visio diagram or a class designer) of the targets contained within your MSBuild script (and how they related to each other).  This product is downloadable as a trial version that expires after 30 days.

These tools just keep getting better and better with each release.  You can read more about these great tools here:

• Team Foundation Sidekicks
• Microsoft Build Sidekick

TFS 2008 Power Tools Released

The Team Foundation Server 2008 Power Tools has been released and is available for download here.  There are several tools/features included in this release - some new, some old:

• Team Foundation Power Tool command-line tool (TFPT.EXE) - contains some new commands for configuring Team Explorer connection settings (tweakui) and for  destroying Work Items and Work Items Type Definitions (destroyWI, destroyWITD).
• Process Template Editor - updated for use with Visual Studio Team System 2008 Team Foundation Server. It also has several improvements, including: the ability to launch standalone without a Visual Studio installation, performance improvements, improved discoverability and bug fixes.
• Custom Check-In Policy Pack - a set of custom check-in polices including:
• Custom Path Policy - provides a mechanism that lets you specify the source control path or paths upon which a particular policy acts.
• Forbidden Patterns Policy - allows you to specify a file extension or a regular expression that you can use to keep certain file types from being checked in to source control.
• Changeset Comments Policy - allows you to verify that the Comments text box in the Check In dialog box is not empty.
• Work Item Query Policy - allows you to specify a team query to which the work item associated with a check-in must belong.
• Team Foundation Server Best Practices Analyzer (BPA) - updated for TFS 2008 deployments.
• Work Item Templates - adds additional menu items to the Team Work Item Templates menu.
• Find in Source Control (NEW) - an addition to the Team Explorer menu that provides the ability to locate files and folders in source control by the item’s status or with a wildcard expression.
• Quick Label (NEW) - allows labels to be easily applied to a given selection of files and folders in the Source Control Explorer.
• Build Notification (NEW) - runs in the Windows task bar notification area monitoring the status of the build definitions you have specified.  It can be configured to show notifications when builds are queued, started, or completed for multiple build definitions spanning multiple Team Foundation Servers.

You can read more about what's included with the TFS 2008 Power Tools release here.

Build Type Settings Changes

I've fielded a couple of questions lately about where some of the settings for build types in TFS 2008 are stored.  In the new version of TFS (2008) some of the build type settings have been moved from the TFSBuild.proj file to the TFS databases (mostly the TfsBuild database).  So, even though you see the settings within the XML file (TFSBuild.proj) the XML settings have no effect on builds within TFS 2008.  However, if you still have VS 2005 (or other "version 1") clients accessing your TFS 2008 build types, you should keep the XML settings in sync with the TFS 2008 database settings.

The settings that have been moved to the database include:

• Description - the build type's description.
• Build Machine - the default build agent.
• Team Project - the Team Project the build type belongs to.
• Build Directory - the directory where the files involved in the build are built.
• Drop Location - the network location where the build files are "dropped".

If you create a new build type, you will see comments within the XML file noting the change in settings location.  For example:

<!--  DESCRIPTION
This property is included only for backwards compatibility. The description of a build definition
is now stored in the database. For compatibility with V1 clients, keep this property in sync with
the value in the database.
-->
<Description>This is my build type's description.</Description>

TFSInfo Updated for TFS 2008

A few months ago I created a simple command line utility called TFSInfo that can be used to display various bits of information about a Team Foundation Server 2005 installation.  I have now updated this utility to work with TFS 2008 as well as TFS 2005.

 

You can see from the screen shot which information is displayed.  In case you can't see the image, the following information is displayed by TFSInfo:

• AT server name
• AT Version
• AT Edition (e.g. Standard, Workgroup, or Trial)
• DT server Name
• DT Server Version (not available for TFS 2008)
• SQL Server Version
• Reporting Server URL
• TFS Installation Date
• TFS Product ID

You'll notice in the list above that the Data Tier schema version is not available for TFS 2008.  This is because the column that's used to determine the schema version in TFS 2005 does not exist in TFS 2008 (at least not in the same table).  I wasn't immediately able to locate a replacement column to retrieve the same information.  If I am able to determine how that information is stored (assuming it is) I will release an update.

The new version can be downloaded here.

NOTE: The Team Explorer Client 2005 or 2008 needs to be installed for TFSInfo to work.

VS 2008 Add-Ins

As I (like many others) make the full-time transition from VS 2005 to VS 2008 I find that I'm having to update several add-ins and utilities that I've grown accustomed to.  Here is a short list of what I've updated so far:

Visual Studio 2008

• GhostDoc 2.1.2 - I've become very accustomed to pressing Ctrl+Shift+D to fill in the XML comments for my code.  I'm glad to see that VS 2008 is now supported.
• Project MRU Cleaner - This is a very handy utility for removing orphaned or otherwise unwanted solutions from the Recent Projects list in VS 2005/2008.
• ReSharper - Although ReSharper does not fully support the .NET Framework version 3.5 yet, Jeffrey Palermo has published some instructions on how to get the latest version of ReSharper working with VS 2008.
• Silverlight 1.1. Tools Alpha for VS 2008 - Nothing new here - it's just been updated to work with the final release of VS 2008.

Team Foundation Server

• VSTS Web Access Power Tools for Team System 2008 - with the new license modifications in TFS 2008 this tool is even more useful than before.  Now all of your company's employees can create work items (e.g. using VSTS Web Access) without requiring a CAL.

I'm still waiting on the full release of Team Foundation Server 2008 Power Tools as I've grown accustomed to using those tools on a regular basis as well - it shouldn't be long.  I also have a couple of add-ins that I've written that I need to get updated for VS 2008 as well.

Omaha VSTS User Group is Coming

A co-leader (Tim Kelsey) and I have been planning on starting a Team System Users Group in Omaha for several months now.  The initial web site is finally up at www.otsug.org and we are excited to have our first speaker, Bill Maurer, scheduled for January 22nd, 2008.  Bill will be presenting on the new features and updates in VSTS 2008.  Time permitting, he will also cover some of what's coming in "Rosario".

With the addition of the Team System Users Group, there will now be no less than four Microsoft technology-oriented user groups in the Omaha area, including:

• Omaha Team System Users Group
• Omaha .NET Users Group
• SQL/BI Users Group - SQL Server/Business Intelligence
• BizTalk Users Group

We will be holding the initial meeting at Farm Credit Services of America (my employer - and a user group sponsor).  Depending upon the preferences of the user group attendees, we will either continue having the meeting at this location each month or we will move the meeting around Omaha (much like the current .NET Users Group).  I will be placing a survey on our site in the next few days to get everyone's feedback and preferences.

I am looking forward to the inaugural meeting and all that follow.  I have no doubt we will have some great speakers presenting on some great topics and will learn a great deal from each other about all things Team System.

If you are in the Omaha area and would like to join the Omaha Team System Users Group, please visit our site at www.otsug.org and click on the "Join the group" link.  Also, if you're in the Omaha area or are just passing through and would like to present at one of our user group meetings, please submit the User Group Speaker Proposal document located in the Shared Documents section of the web site.