My „new“ issue tracker installation

I’m absolutely relying on working with issue trackers for managing features, bugs, and releases. Although it’s always a bit cumbersome to teach (new) clients how to properly use it (it takes quite some hand holding and improving their tickets), sooner or later they all realize that it’s way better than the chaos we get by tossing Excel sheets back and forwards.

Although we shut our company LaTe App-Developers down last year, my colleague and me are still using our old redmine 2.x installation to support existing clients. For new projects, I recently started to look into the current state of issue tracker offerings. My needs are:

  1. Open source – I don’t believe in closed source solutions for such a critical thing in my daily routine.
  2. Simple & efficient – I don’t need a feature monster, I need something that I and my clients can use and that doesn’t get in our way.
  3. Self-hosted on debian 7.x – I know it’s quite some administrative work to get things running smoothly, but once in a while I enjoy these kind of tasks.
  4. Configurable task states and workflow – My status flow is usually open => reproducible => in progress => testable => closed.
  5. Remote GIT repository integration:
    1. A combined activity screen where I see not only tickets, but also change sets.
    2. Being able to advance the task state with commit messages.
    3. Fetching new data by using git hooks! No cron jobs, no pulling.

As I’ve mentioned, we previously used redmine and this is what I’m familiar with and what I love to work with. In the past (when my requirements were not developed yet), I also used trac, mantis, and bugzilla – but neither of those got me hooked.

Despite being somewhat satisfied with redmine, the last time I researched the market was five years ago, so I set out to do another survey – to see whether there is anything better than redmine meeting my requirements. I spare you the itchy details, but after looking and trying for some weeks, there were only three contenders left:

  1. Good ole‘ redmine, this time in version 3.1.
  2. OpenProject, a fork of the (now defunct) ChilliProject – hence a 2nd order fork of redmine.
  3. Phabricator, the new hotness introduced by Facebook, Inc.

OpenProject looked interesting to me since it basically is still redmine, but with a focus on a more streamline UI and better usability (and more frequent releases). Installation was pretty good, since finnlabs (the company that is steering its development and offering professional services around the product) provides packages. Everything worked pretty well, but at the end of the day though, it wasn’t that much of a step-up from redmine.

Phabricator is pretty impressive. Installation is painless (On most systems, PHP still has the better out-of-the-box experience than Ruby and Rails) and the web GUI looks amazing. Although the individual parts are very strong and it has a lot of features that redmine lacks, the configuration UI is pretty barebones (for custom ticket states, you have to edit JSON files) and it doesn’t felt as integrated as redmine. It has great potential though, perhaps I just need to play with it for a longer time. I left my installation intact and will use it for an internal project for a while.

For all other projects though, I have decided to come back to redmine. To spice up the look and feel, I’m using the Circle theme from RedmineCRM (who are making some great plugins for redmine) and some of their plugins.

One thing that’s always a bit of a nuisance is the git repository integration without pulling or stalling when it reads the changesets while you are, say, querying the tickets. Phabricator comes with a dedicated daemon that eases this part, I think that’s a way redmine et. al. should look into, as well. For redmine 3.1, I got it working with their new (to me) repository web service. If you don’t have the repository on the same machine as your tracker installation, the ideal system has the following parts:

  1. I push a new changeset to my repository. A simple post-receive hook on my gitolite installation then calls the redmine web service to trigger the next step, e.g.
    curl "http://<redmine url>/sys/fetch_changesets?key=$apikey&id=$projectid" &
  2. The redmine webservice updates its local mirror of the repository by calling git fetch. This can easily be done with the redmine plugin gitremote.
  3. The redmine installation processes the new changesets, checks for special commit texts, and updates its internal databases accordingly.

The hardest part of that is debugging, when something does not work (as always…). In my case it was a custom SSH port on my machine, which made it silently fail fetching new changesets until I realized that 🙂

I still recommend redmine, if you have similar needs as me. Yes, it may not integrate the latest web technologies and look a bit rusty (which you can improve by using a theme), but it’s solid and does not get in your way.



Drop a comment

Your email address will not be published. Required fields are marked *