November 9, 2007
Get Files For Build From TestTrack
Works with TestTrack 2008
Works with Surround SCM 2008When creating a build, it is imperative to include the revision of the source code files that contain the changes that fix defects that are supposed to be included in the build. Poor change management can lead to builds that do not include fixed defects or, even worse, reintroduce old defects. Seapine's ALM solutions are aimed at avoiding these types of problems. Seapine CM gives you the ability to attach source code files to a defect and associate a defect fix event with the revision of the source code file that addresses that specific fix. If a build is needed and it has to include a fix for a specific defect, you need to make sure that the correct revision of the source code file is included in the build. The following example illustrates how you can use TestTrack automation rules and the TestTrack SDK to facilitate this process. [toc]
System RequirementsThe following example was created using TestTrack 2008.0.1 and Surround SCM 2008.0.0. The SOAP application was written in C# using Visual Studio 2005.
Modyfying the WorkflowThe workflow in TestTrack must be modified. This is the only way to create an action, since you cannot just add buttons. The only way to add a button in TestTrack is to add an event to the workflow. Here you have two options:
- Create a state changing event.
- Create a non-state changing event.
- If the event changes the state, it could be useful to let other users know that a build is in progress. However, you must make sure that the state is changed after the build process is completed. This could probably be automated in the build script.
- If the event does not change the state, then some filtering will have to be performed. The automation rules are set to trigger when a defect enters a state, or when any event is added, edited, or deleted. You cannot trigger on a specific non-state changing event.
Setting the Automation RuleI will not go into the specifics of how to create a filter and the automation rule, since these are also basic functions covered in the documentation.
Creating a FilterBefore setting the automation rule, we must create a filter. As indicated above, I am using a non-state changing event and that means I am not able to select an action specific to my event to fire off the trigger. Through filters, you can see if a specific event has taken place in the last hour. This is the smallest amount of time that can be used with the filters. Figure 2 illustrates the filter created.
Setting up the TriggerA trigger is set up using the filter created above, and it points to the SOAP script ("GetFileForBuild.exe"). The automation rule summary is as follows:
[Get File(s) for Build] applies to [defects] passing filter [Get File For Build] -- when [has event added, edited, or deleted] Run executable located at "D:TTScriptsGetFileForBuildGetFileForBuild.exe" [after] save
Downloading the SOAP ScriptYou can download the C# project I created using Visual Studio 2005 from here.
Script Requirements/Limitations/General Notes
- Even if you cannot use this project, you can use it as a guide to writing your own script with a different language. You can open the .cs files using any basic text editor.
- Everything is hard coded in this script. You will need to edit the project files to match your server's address, the TestTrack project name, and credentials to be used.
- Another option is to have the automation rule launch a batch file that runs the script and passes some arguments. The arguments could be the SOAP account to use, the TestTrack project name, etc. This would make the script more flexible.
- The application can only handle one "fixed revision" per source code file. It simply retrieves the value and passes that value in the get operation. If there are multiple fixed revisions (as in "6, 9"), the get opertaion is likely to fail. If there is no fixed revision, then the script will get the latest revision of the file.
- The get operation places the files in the working directory. If there is no working directory set, the get operation will fail.
- The script could be enhanced to parse the event notes. It could possibly look for a token that would allow the user to specify the destination of the get. At this time the get operation will place the files in the working directory.
- This could be further enhanced to create the directory structure to mimic the repository structure of where the file is located.
- The filtering logic used in the script could be enhanced to test more than one specific workflow event.