A good and complete Continuous Integration (auto-build, auto-test, etc.) system should include Source Control Management (SCM) component and Issue Tracking component. And these components should be well integrated.
In our company, historically the following were used:
- CruiseControl.NET - as Continuous Integration engine
- Microsoft Visual SourceSafe – as SCM
- Axosoft OnTime – as issue tracking tool
CruiseContril.NET integrates with VSS easily and smoothly. The missing part was integration between VSS and OnTime.
The solution described in the article provides for a convenient 2-way integration between VSS and OnTime.
Interface to OnTime is localized in the code and therefore the solution may be easily modified to provide for VSS bridging with any other Issue Tracking tool.
How Integrated Issue Tracker Should Work for Continuous Integration
A typical workflow should be as follows:
- Team lead assigns the item (bug, task, feature, etc.) to developer
- Developer gets the code from SCM and does the necessary modifications
- As soon as developer commits his changes to SCM, he should be prompted to establish the link (association) between the tracked item and committed source file versions
- When developer completes his work, he sets the status of the work item to “ready for build”
- The next scheduled (or immediately triggered) Continuous Integration service gets the source code from the SCM, includes file versions associated with completed work item and executes automatic build and tests
What is OnTime and Why Does It Not Work for Continuous Integration without the Bridge
OnTime is a software package from Axosoft that provides for:
- Bug / Defect Tracking
- Feature / Requirements Management
- Help Desk Incident Tracking
- Workflow Automation
- Scrum / Agile Project Management
and more. You may find information on the product here.
It has enough functionality be used as an Issue Tracker too. It has:
- Feature, Task, Defect types of items
- Ability to assign the issue to developer
- Configurable items properties such as:
- Workflow step
- SQL query may be used to get the filtered list of items
OnTime even has the SCM connectivity:
- Each item has SCM Files property
- It may be seen as the list of files under SCM tab of the item
- The list shows files’ versions and history
- OnTime provides for checking files in and out of SCM
The following picture shows SCM tab on the item dialog:
So, theoretically, OnTime may be used as an Issue Tracker component in Continuous Integration system. But practically, it does not work.
Because it is one-way connectivity:
- Developers mostly check-out and check-in files via Visual Studio
- Additionally the team may use SCM (Visual SourceSafe) GUI client
- None of these tools have any interaction with OnTime
- No source-work item association gets created
Solution: VSS – OnTime Bridge
To overcome this deficiency, I have developed a custom solution – VSS add-in:
- Uses Interop to access VSS COM interfaces
- Intercepts check-in and add-file VSS events and invokes GUI component
- Does not interfere with command-line VSS operations (does not affect auto-build)
How It Works
Plug-in intercepts VSS check-in event and invokes VSS-OnTime Bridge dialog:
The developer selects the OnTime item to associate the file with and clicks Select button.
Refresh button might be useful, if the developer does not see his work item in the list. It means the work item was not properly assigned to the developer. In that case, the developer
- opens OnTime
- assigns the work item to himself
- clicks Refresh button to update the list of work items (Defects on this picture)
Let us verify how it worked. Check the file history of the associated file in VSS.
Note it has been labelled as D1091 (Defect 1091):
Now check the item in OnTime: association with specific version of the source file was added under SCM tab:
To include the item into the next build:
- Developer sets in OnTime the workflow step of the item D1091 to Build-ready
- Build script queries OnTime database for build-ready items
- Using the item-source association build script gets specific version of each specific source file
- Candidate for the next Baseline is built
VSS Add-in Basics
These are well described in this article.
After you have built and registered your add-in (Visual Studio will register it for you during the build, by the way), do not forget to place ssaddin.ini into the same folder where ssapi.dll resides.
Typically: C:\Program Files\Microsoft Visual SourceSafe Ssaddin.ini is a text file with just one line:
Microsoft.SourceSafe.EventHandlerGF = 1
How the Code Works
The solution has just 3 classes:
public class IvssEventHandlerGF : IVSSEventHandler, IVSSEvents
which I have humbly embroidered with my initials – “GF”, knows nothing about OnTime. It just implements
IVSSEventHandler interface and has just one additional method:
private int RequestLink(VSSItem vssItem)
This method is called every time the check-in or add-file event is intercepted.
This method just creates the instance of
Scm2OtForm class and calls its
There are few more tricks around this call though.
Trick 1: That would be nice to persist the size of the dialog. Imagine you have carefully resized the dialog so that all details of the work items are visible in the
datagrid. And on the next check-in, you are surprised that the dialog shrank back to the default size. Not nice. I am sure there are many smart ways and classes that persist the size of the dialog better then I did. Being a novice to C# and .NET stuff, I did it in a simple and straight forward way.
Trick 2: That would be nice to persist your selection. Imagine you are checking many files in order to complete your work item. You are checking files one by one, and for each one you have to select the type of the work item (Defect, Task or Feature) and then select the item from the list. Much better if the last selected item would be selected by default. And all you have to do is just click Select button.
Trick 3: That would be nice to provide for a batch check-in. Imagine you are creating the whole folder in VSS and populating it with a bunch of files. And for each file, you will have to click the same Select button. There is a hard-coded (for simplicity) 2-seconds interval. If the time between events is less than the interval, the dialog is not shown and the same association label is reused for all batched check-ins.
Trick 4: When labelling the file, VSS creates a new version from the original one. And this creates the problem: OnTime version is now 1 less than the VSS version.
- First label the checked-in version,
- then get the version number of the labelled item,
- and only then call
public class Scm2OtForm : Form
also does not know anything about
private OnTimeAdapter.OTAdapter _otAdapter;
which has all the knowledge about OnTime and may be easily replaced with another adapter to another Issue Tracker.
This is the pop-up dialog (see the picture above) that displays the grid of work items and prompts to select the item to associate the VSS item with.
public class OTAdapter
has all the knowledge about OnTime, including the SQL connection string.
I have mine hard-coded for simplicity. It is easy to make it read the settings from the config file or from the registry, if necessary.
I have requested from DBA to create the specific “
vss2ontime” user and have created stored procedures “
sp_GF_GetTasks()”, etc. to retrieve the lists of OnTime items.
If for any reason SPs are not welcome in OnTime DB, it is easy to rewrite the code to perform direct SQL queries.
The plug-in was written a couple of years before and, unfortunately, soon after that, it was decided to decommission OnTime and switch to another item tracking system.
The switching is still not complete though.
As a result, my code stays in its initial raw state without any major changes or improvements.
I still do believe it might be useful to dev teams that are using OnTime or similar trackers with VSS.