Redmine (or Trac) integration with customer issue-tracking system

Question

I'm working in a software development area in my university, and we've noticed we need some system to track errors and bugs, who and when it is dealt with. I've researched some software management/bug tracking applications, with Redmine being the one that appeals to me the most because of its simple UI (actually I discovered that our server has one system, Trac, already installed, but it has never been used at its time and my colleagues told me it would take the same time to use any).

However, a colleague told me also that he has the idea of implementing a customer issue-tracking system in the medium/long term (he told me about creating tickets for users' problem, search into a knowledge base of common problems, and mark frequent problems to deal with them. It seems that things like OTRS are close to what he was thinking about. He's also researching about ITIL).

As far as I know, the developer issue-tracking system and the client problem-tracking system are different, and they must have some kind of integration between them. Or aren't they? In case it does, my question is:

Is it possible to integrate Redmine (or Trac, if it's easier, or in general a project management/bug-tracking system) with this kind of customer issue-tracking systems? Do I have to worry about changing my project management system in the future to implement that? Or is the implementation easier with some of them?

Answer 1

I'm writing this from the perspective of Redmine. I haven't used Trac and only massaged the source with my eyes (not even reading it). At a high level, it appears to be similar to Redmine so many of the things that I say may apply to it too.

The first question that you need to look at is the integration between the bug tracking (and code change) side and the "customer facing" issue tracking. Different places may allow for a degree of openness that is not available in others.

• A closed-source software product certainly won't let the code changes get anywhere near the customer facing bug tracking system. The risk of having some code getting out is a worry for many of them.
• An open-source software product will often host the source code and bug tracking right alongside the customer issue tracking (they are one and the same). This can be seen in both Redmine and Trac.
• An academic setting... well, its probably somewhere in between.

That last point is key - is it a problem if the source gets out? Or for that matter, is it a problem if people see the discussion between developers of the product in the notes of an issue?

Redmine has the ability to restrict which certain users can read. You may have individual notes marked private or things such as "only people with the programmer role can see the repository."

If this is acceptable, the easiest thing is to integrate the end user issue tracking and bug tracking in the same system. You will likely want to separate "bugs" and "issues" from each other, though note that there is a relationship between them. An end user issue may be caused by a bug, or it may be something the end user doesn't understand.

Issues and bugs have different work flows - issues may go through something like "new -> confirmed -> waiting for fix -> resolved" while a bug may go through "new -> assigned -> working -> code review -> working -> code review -> deployed -> closed" or something like that. There are likely as many work flows as there are installations. Having a "blocked by" relationship from the issue to the bug allows you to easily relate the two systems together.

All of that was assuming that it was acceptable to have one system host both, you will then find yourself with two different systems - one that is customer facing, one that is developer facing. This may involve a bit more work - somehow, someone needs to bridge the gap between the two - developers need to be aware of bugs that are discovered by the end user in their bug tracking system.

I haven't found a modern bug tracking system that plays nicely with others. Everything tries to be self contained and when commercial products have bug tracking systems, they make it so that it's easy to migrate to it and use everything within its own product line. You may find an API that lets you do some things, but for the most part - nope.

The question here becomes what is the workload and how does one want to integrate the two (picture two spoiled children sitting with their backs to each other not wanting to play)? Is it enough just to have a link from one system to the other? Is the amount of new issues low enough that this can be done by hand? or will you need to start exploring some way to poll from one and update the other?

Make sure that when integrating the two systems that you use the API rather than trying to go behind its back and tinker with the database with updates directly. There are dangers to that - the table structure of modern bug trackers is a big large and they are managed in the application. Going behind the back of the application may cause issues with data integrity. As mentioned before, instead of updating and inserting at the database, use the public API for the application (Redmine's API for issues for example).

The extent of the business logic and the integration points are something that needs to be examined before jumping off and doing it. Which way does the data flow (both ways gets very interesting at times) and what data flows. Are you copying issues into bugs once they reach a certain state? How do you keep track to make sure you don't create the same issue again and again (need to update the data model of the bug tracking system)? What happens when an issue is marked as closed in a bug tracking system - does that flow back?

All in all, its probably simplest to try to use the same system and manage the permissions / customize it so that it works the way you want it to if it is not critically bad if some bit of knowledge from the developers leaks out.

Answer 2

Ultimately there is never any integration between these things. They aren't designed to work with "some other" tracker. Or if they have an API, no-one uses it to integrate it with anything unless you're in a large enterprise shop, and then integration will end up being with something like Sharepoint (sigh).

The best thing you can do in such cases is to add a custom field to every internal bug item that contains a reference to your external bug tracker. It's a manual process and prone to error, but it's the only realistic way you can tie the two together. The rest of the time, you simply use them separately - no data gets exchanged between them.

If you can use the same one, then do so, but I know many places cannot do this and there's always a disconnect between the support teams tracker and the dev teams tracker.