January 6, 2009
Attach TFS Check-in to TestTrack
Email sign up
Works with TestTrack 2008 and later and Team Foundation Server 2008This article outlines how to create a check in policy in Team Foundation Server, which checks the comments passed in a check-in event, ensures that a defect number is included in the comments, and then updates TestTrack. You'll need:
- The TestTrack SOAP SDK installed.
- The path to your TestTrack SDK installation. If you're familiar with how web servers work and your IT environment, you can probably guess this. If not, ask the TestTrack administrator or IT staff for help.
- Team Foundatin Server and the necessary permissions to check in files.
- A Team Foundation Server Check in Policy that automatically associates check-ins with one defect in TestTrack.
- Review the code we're going to use to implement this policy.
- Go through an example of using the policy.
Team Foundation Check-in PolicyThe policy file we will be using is written in C#. Most of the examples provided are in C#, so this made it easier to simply add the section for TestTrack. Once called by Team Foundation Server, the policy file does the following:
- Uses the Team Foundation Server API to fetch the comments and list of files changed by the changeset.
- Parses out the comment.
- Looks for the following token in the comment: <:defect#:>. An example would be: <:12:>
- If the token is found, parses out the files submitted with the changeset and links them to the SCC tab of the referenced defect.
- If the server where Team Foundation Server is running is also running share point, you may need to install the TestTrack SOAP CGI executable on a different web server altogether. SharePoint seems to take over IIS, and if you must run the TestTrack SOAP CGI on the same IIS instance, you may have to assign a different IP address to the web site running the TestTrack SOAP CGI.
- The code could be enhanced to be more stringent when parsing the comments. At this time, it only looks for the token elements ("<:" and ":>"), but it does not check that the open element is before the close element.
- The code could be enhanced to first make sure that the defect exists in TestTrack. If not found, a meaningful error message is displayed to the user.
Set up the custom check-in policyI am going to have to defer to the experts at Microsoft for this. Everything I needed to set up this I got it from here. While this article talks about version 2005, it also applies to 2008.
Configuration FileThe script will read in information used to connect to the TestTrack server from a configuration file called TTConfig.xml. This file should be located in the same directory as Visual Studio (devenv.exe). Following is a sample config file that is saving all connection information
<?xml version="1.0"?> <ROOT> <ServerAddress>http://localhost/scripts/ttsoapcgi.exe</ServerAddress> <Project>TestTrack ALM</Project> <TTUserName>Administrator</TTUserName> <TTPassword>password</TTPassword> </ROOT>Following is a brief description of each item in the config file: Server Address: The URL location of the TestTrack SOAP CGI (ttsoapcgi.exe). Project: The TestTrack project to log in. User Name: User name to use to log in to TestTrack. Password: Password of the above user Note: The user name must have the permission to log in via SOAP enabled in his/her security group.
Testing the policyNow we can actually use the policy!
- Check out a file from a Team Foundation Source Control folder.
- Edit the file and save change.
- Check in the change.
- Enter <:1:> This is my first attempt at using the check-in policy that will integrate TFS with TestTrack!! as the comment for the check in.