Posterous theme by Cory Watilo

Exception Tracking and JIRA

Keeping track of exceptions, especially in a large project like Mobile Oxford, can be at times a challenging task. The solution we currently use is to have an exception generate an e-mail to us, with information about the exception, and the request that caused it. Some clever hashing, combined with a decent e-mail client, allows these e-mails to be threaded, but languishing in our inboxes probably isn't the best way to handle them. Unhandled exceptions are bugs, and should be handled as such within our current bug tracking systems.

One thing we've started doing at Mobile Oxford is looking at the tools we're using, particularly for bug tracking. Previously we used SourceForge, but found its tools to be below the standard we're looking for. We looked at a myriad at other tools - Github, Launchpad, Playnice.lyHoptoad and Lighthouse, with mixed reactions. Hoptoad in particular had us interested, especially with the django-hoptoad integration, which would make it easy to drop in to the Mobile Oxford deployment, but Lighthouse's issue tracking functionality let it down.

Internally, OUCS uses JIRA as a tool for bug tracking, which is an insanely powerful tool that does everything we want, and more, so inspired by Hoptoad and the django-hoptoad library, we investigated getting Django reporting exceptions to JIRA, with the same sort of duplication checking, etc - and an afternoon of coding later, we're successful. It's external to the Molly Project, and can be dropped in to any Django project as middleware. There are a few more settings than I'd have liked to see in the finished product, but that just comes down to the massive flexibility of JIRA.

The package is hosted on Github, feel free to fork it, and there are some simple instructions in the README on how to add it, and the settings that need to be added to your settings.py to get it working - let us know your feedback, if you find it useful, or if you spot any bugs!