XPlanner and Defect tracking systems (DTS) can be considered as planning tools. XPlanner however isn't meant to do the extensive data gathering and work flow process management that you would expect from a Defect tracking system. However some Defect tracking systems overlap with xplanner and we must provide a seemless integration between both.
Here is the proposed division of responsability:
- The Defect tracking system is used as the repository of work items
- XPlanner is used to plan iterations and releases
Given this split the first step would be to provide a way to:
- Populate stories/tasks based on defects in the DTS
- Manage state synchronization between stories/tasks and their associated defect.
Initial population
Iteration population
The simplest way is to add a state to the defect life cycle to indicate when a defect should be picked up by the next iteration. Within the current iteration, a planner could synchronize xplanner with the DTS and automatically create stories or tasks (See below) for each defect. A pluggable adapter would handle network/db connection and story/defect attributes mapping.
State synchronization
There are 2 directions to the synchronization
XPlanner -> DTS
On defect story/task update, XPlanner would update the associated defect.
 | Implementation note This requires a DTS that can be updated through direct DB manipulation or through a remote interface. The DTS adapter would be notified to take care of the synchronization. XPlanner business objects have already the capability to store extended attributes. These attributes may be used to stored the mapping information like the defect id. In the future we would add the capability to customize the view of a "defect" story/task accordingly so more attributes from the dts can be shown/updated from xplanner. |
At this point we are looking at integrating with ClearQuest and JIRA out of the box.
Story or task per defect
There are 2 schools of thought to map defects in xplanner:
- Create a story per defect.
- Create a task per defect in a special story in the iteration.
At the present time (0.6.2) stories have no type. Tasks are the only things that can marked as Defect. Task per defect would be then easier to implement.
In addition once release planning is supported, defect resolution planning won't be something that would follow the same process as stories: we don't know how much will have to be done. The only thing that can be done is to allocate a budget for defect resolution. A marker story to do that is the easiest. Concrete defect tasks would be then assigned to that story when appropriate.
XPlanner stories to support DTS synchronization
The task or story that the integration would create would be slightly different than normal ones. XPlanner would know they are external and would maintain the links to the external system (new index in db...). A particular DTS integration could rely on certain xplanner services to make its life easier:
- DTS id storage
- Find entity by DTS id
In order to make synchronization implementation easy I would like to propose a plugabble handler that would take care of:
- Wiki scheme to link to defects: jira:XPR-1
- Change propagation: handler would be notify anytime an external story/task is updated in xplanner
- Provide the DTS id for a story/task
- Provide a set of configuration properties to be rendered in the project options page (the idea here is to be able to "merged" the adapter configuration properties like the dts url and project with the builtin project property.
This is the uncomplete list of "stuff" to do
| Name | Description |
|---|---|
| Add a "Sync with DTS" action on iteration | At iteration planning time allows to grab all proper defects |
| Store DTS id and allow to locate element with it | Support for adapters implementer |
| Notify external system of changes in xplanner | Real time update |
| Provide a offline DTS synchronizer | This would take care of system like ClearQuest that are hard to customize to provide a real-time integration. We would need a quartz job that kicks off a global refresh of each external stories/tasks and add new ones. This would work both ways |
| Implement JIRA adapter | |
| Implement ClearQuest adapter |
Track+ Integration
I just attached the source of our Track+ integration. This is intended as a discussion base for how a DTS integration could be done. The uploaded code is not very clean (or documented) and cannot be used as it is, as we are using a slightly modified database scheme in our system. But we are using it for more than three months now.
We implemented a DefectTrackerManager that is part of XPlanner and manages 1 to n DefectTracker-Adaptors. The DefectTracker implement the connection to the DTS and provide collections of defects to be worked on in the current project iteration and can update defects in the DTS. Our goal was, not to write any code in the DTS just manipulating the database of the DTS (directly or through APIs).
The DefectTrackerManager's synchronize method is triggered by a Quartz job. There are three reasons for taking this approach in contrast to a "real time update" when a task in XPlanner changes:
- We are updating the XPlanner Timeentries and Tasks through our own time-keeping application. (In fact our time_entries table is a view inside our Firebird database.) Therefore XPlanner might never know that a task was updated.
- We simply donnot need real time here. All our reports are generated at night.
- we did not want to dig too deep into the XPlanner code
We are creating several stories in the current iteration and populate them with the defects that are currently due (The DefectTracker decides which defects qualify.). Each defect is a separate task. All defects of a certain priority go into the same story. The DefectTracker maps DTS priorities to story priorities. The population process also moves or continues defect-tasks that may already exist in XPlanner.
To identify the defect associated with a task, we added a defectId attribute to the Task class. (To realy support more than one DefectTracker we need to add an AdaptorId too).
During the synchronisation process the DefectTracker is informed about the state of all XPlanner defect-tasks (Open, in progress, closed). Again the DefectTracker decides how to handle this information. Furthermore the tasks are updated according to the current state of the defect in the DTS (task is closed, when defect was closed or is no longer due for now).
The DefectTracker is also responsible for mapping users and projects. In our case that is quite simple as both systems use the same databasetables to store users and projects. With other systems this might be tricky as the names of projects and users might not be identical in XPlanner and the DTS.
Plans to integrate with XTracker
XTracker is inspired by RT and XPlanner.
There is a demo of XTracker up at http://dev.pappin.ca/xtracker. Username xtracker, and password xtracker. It's only about 25 hours of work so far, and I have yet to implement some of the core features for the first release candidate. Expect it to be buggy or crash on you (I'm using hibernate, and I have some connection pool stuff to work out).
I'm actually interested in integrating XTracker with XPlanner, but support from both directions would result in a better integration. At the very basic level, I want to add a button that will add a ticket
to XPlaner as a story, I haven't worked out the details yet but some ideas are:
- Add Story to XPlanner from XTracker ticket
- Tracking closed tickets and their linked Stories
- Tracking hours worked
- Associating Projects
I expect this Ticket-Story linking to work in realtime so that updates to one reflect in update to the other.
It would be best if the ticket was simply added to the backlog of a project, but I always create a "Project Backlog" iteration myself and new stories go there.
