When we first arrived at Armedia a few months ago, we did a quick inventory of the internal tools we use for development. We were excited to find JIRA; yes, the open source, issue-tracking system from Atlassian. We had previous experience with JIRA from previous companies, and found it to be an extremely useful product for issue tracking/resolution/reporting.

However, since we began working to customize our JIRA installation for both internal and external clients, we’ve developed somewhat of a love-hate relationship with it . For example, we appreciate the fact that the open source community is available for questions and issues we run into during development, and in general they are helpful and quick to respond. We both also appreciate the open source developer community that has produced a cornucopia of plug-ins and gadgets for JIRA – many of which are excellent. In particular, we like the Greenhopper, Craftforge JQL Functions, Customware Visibility, and Issue Collector plug-ins, which have addressed or resolved many functions we needed to perform.

Our main grievances with JIRA are in relation to their user interface and basic shortcomings of the application. There are pieces of functionality that are missing or just doesn’t make sense – case in point, not being able to copy a project (especially if they share the same custom workflow, permissions, notifications, fields, and screens).  As many of you know, setting up another project with duplicate configurations is a time-consuming process when you have several projects that share the same configuration.

Another example is not being able to backup selected projects (you can only backup the entire JIRA database). We were pleased to find, however, that the ability to expand/collapse swimlanes on a Rapidboard (previously available, but noticeably absent from JIRA Greenhopper 5.10.x) has been recently restored in version 6.0.2 of the JIRA Greenhopper module.

The JIRA community has been very vocal in its desire to correct or extend JIRA’s functional capabilities, as evidenced by the numerous enhancement tickets that are currently submitted. We’re sure our organization will be adding to that count very soon!

Today, we are proud to have a stable, yet fairly customized JIRA environment.  We are now exploring the use of Confluence and integrating it with JIRA as a reporting mechanism. The other area we’ll delve into is JIRA security mechanisms. If you’re going to make JIRA accessible to a multiplicity of internal and/or external audiences, you will want to investigate how JIRA security can dovetail with your network directory service – in our case, Active Directory roles/groups. This is of keen interest when balancing the right security schema while keeping administration to a comfortable minimum.

Key tips so far?  Here’s our take:

• Take time to understand the default schemes, user groups, and roles setup in your system
• When creating new projects, invest the time to create your own custom schemes (don’t use the defaults unless absolutely necessary)
• Leverage the Atlassian community – they are a treasure trove of lessons learned, workarounds, and just plain answers to your questions!
• Keep your JIRA instance up to date! I’ve seen two point releases come out since June that have addressed key defects or enhancement requests

So, next stop – JIRA & AD security, and JIRA + Confluence Integration. Can’t wait – its gonna be a wild ride, so make sure that you stay tuned for updates!