JIRA articles are now at jiradev.blogspot.com

I've started a new blog for JIRA-related posts over at jiradev.blogspot.com. Future technical JIRA content will appear there instead of in this blog

~Matt

How irritated customers obey a power law

There are over 4000 open issues about JIRA that people have voted for. The most popular vote has 592 votes but most issues have zero votes. I found a suprisingly good line to fit the data with a correlation coefficient 0.9882, if Excel is to be believed. I'm not sure that I actually believe in predicting what people vote for, but I guess this is one way of measuring your progress is how the coefficients of the predictor change over time. The flatter the line, the better job you are doing of evenly spreading out customers' irritation with your product.

As of July 2010, the coefficient of irriration for JIRA is -0.65.

ASCII art in log files and showing my age

What is that? Well, let me tell you. It's supposed to be some ASCII art that my new-fangled JIRA bug tracker spits out into its log file at start up. It's supposed to serve some useful purpose. It fails (fails, I tell you) because when you view ASCII art that is longer than 80 characters in a terminal (this is a log file, remember) that text art just wraps around and resembles line noise. Yes, line noise like they used to have in the last century.

What's that? You think ASCII art is cool? Well so do I, in it's place. Which isn't my darn log files. What am I going to do about it? I'll tell you, I'll show 'em! Now get off my lawn.

One Bug, Multiple Branches

I enjoyed presenting and discussing some new ideas about how to use JIRA to track bugs in different branches along with their associated builds. This was all at the April San Francisco Atlassian User Group last night, kindly hosted by Atlassian.

My idea is to create a new issue type named "Build" and then create a new build issue for every build. Ordinary bugs in JIRA can then have regular JIRA links named "Present in Build" and "Absent from Build" connecting them to the specific builds in which they are found or fixed. The interesting part is that if you link the Build issues to other Build issues, you get a tree of related builds such as the diagram above that you can then use to deduce which bugs are present in any given release, and also which releases a given bug is likely to be in. Useful information that is rarely available in current issue trackers.

My presentation is available via Google Docs. Feedback welcome, as are beta testers for the ideas in JIRA.

Verification code for Empire Avenue: EAVB_KMCAYMVSLW

Handling large numbers of JIRA projects

Once you have a large number of projects in JIRA creating an issue can become a bit tedious, scrolling through the long list of projects to choose just the right one. JIRA (Enterprise edition) already provides Project Categories that you can group projects into, so without further ado, here's a JSP hack to reduce the size of that list of projects by letting you select a project category first.

Installation

The modified file for JIRA 3.13 is createissue-start.jsp and replaces the file of the same name in your JIRA instance. There should be no need to restart JIRA. The usual disclaimers apply, drink responsibly, don't drive and derive etc.

Should you go to AtlasCamp? Hint: yes!

This post is a friendly sales job for AtlasCamp, the Atlassian developers get-together that's happening October 21-23 in Half Moon Bay, California.

Cons

- Costs a bit of money this year ($200 instead of free)
- er ...
- that's it!

Pros

+ If your company depends on JIRA or Confluence and you've changed them somehow, this is the best place I've found for technical questions
+ Friendly people who write useful code at this conference, not just vapid schmoozing
+ Good presentations about what's changing in the products you depend on
+ Plenty of opportunities to tell the core Atlassian developers and top management exactly what you think of their products

See you there.

~Matt

Does this bug tracker make me look whiny?

I submitted a bug about JIRA to Atlassian recently and wondered who reported most of the bugs in their very public database. No surprise, about half of the ones in the last year are from Atlassian employees.

Over the last three years, it's a tie between Neal Applebaum and Sergiy Lizenko (ILS-Ukraine) who each submitted 81 issues, and myself trailing in third place with 39 issues.

~Matt

Making it easier to maintain JIRA workflows

This is one for JIRA admins.

I've had to track down a few problems recently that were related to fields not appearing on screens, especially when issues were changing their status. The cause turned out to be customized Transition Screens. A Transition Screen is the screen that is shown while you are moving from one status to another, and it's easy to forget which screen goes with each transition.

Sure, you can click on each transition and look for which screen is being used, or you can look at the list of screens and see which transitions used each screen. However, as the number of transitions and screens begins to grow, workflows become harder to maintain. The precision hack shown here helps with this. Click on the image to enlarge and look at the "Transitions" column. Each line has had the text "with the screen "added.




When you view any JIRA workflow with the "View Workflow Steps" screen, the transitions between steps (statuses) now have their screen information shown as well. At a glance, you can now look at a single workflow and see which of your transitions have those troublesome custom transition screens.

The file to change is

atlassian-jira/secure/admin/views/workflow/viewworkflowsteps.jsp

and the modified version can be found here. This was tested with JIRA 3.13.2 and is also a good example of what you can do with JSP if you have to.

Tracking Those Personal Issues

Geek Hero Comic

I suspect that some people use bug trackers for even odder things. JIRA has a personal license for just those sort of, well, personal, things.

JIRA Customization Guidelines

These are a few slides written at AtlasCamp today. The slides contain some general guidelines for customizing JIRA.

AtlasCamp

So I've booked my place at AtlasCamp, Atlassian's first customer/developer love-in happening this November up in Marin County, CA. I'm not really sure what to expect except lots of product discussions, and I suspect a drink or two. Maybe we'll write some code, I don't know. I'm looking forward to it.

Anyway, if you're also going and would like to carpool from around San Jose, I'll have a couple of places in my car.

~Matt

Atlassian User Group, Palo Alto

Well, I enjoyed the Atlassian User Group yesterday at Stanford. I'd forgotten just how complex getting a parking spot can be there, but I made it with only a few surprised comments from my new mistress. I gave a summary of my JIRA MultiSite post, but the things that I enjoyed most were:

- seeing what's coming up in JIRA 4.0 (nice work from Nick Menere and others)

- asking Mike (CEO) both technical and business questions and seeing him handle both well

- meeting lots of smart people using JIRA, with an eye to new clients of course.

The sponsors Stanford and WANdisco provided a good spread of food, which always helps such things. I'd recommend any JIRA administrators in the Bay Area come to the next one.

The February issue of Python Magazine is out and contains my article "Using Python and SOAP to create a CLI for JIRA" about the Python CLI that I wrote for JIRA a while ago. The article's summary reads:

Many web applications include an API that lets you interact with them from the command line as well as with a browser. In this article, Matthew shows how to build a command line interface for JIRA, a well-known issue tracking system, using Python and SOAP. JIRA is a Java application, but using SOAP allows you access to many of its features using just Python.

One hint that I wish I had remembered to add is that when you have a redirect to your JIRA server, for instance when http://jira.mycompany.com is redirected by Apache or IIS to http://jira.mycompany.com:8080, you may see your login mysteriously fail. The answer is that you have to use the redirected URL with the JIRA CLI. You can find out what the redirected URL is by running the CLI with the argument -v10 to increase the logging verbosity and look at the line that starts with "Host". This example shows that the port to use is 8080.

*** Outgoing HTTP headers **********************************************
POST /rpc/soap/jirasoapservice-v2 HTTP/1.0
Host: localhost:8080

Finally, a use for those JIRA user properties

One of the most useful JIRA plugins I've found is the JIRA Toolkit, described as "a bunch of neat custom fields Atlassian have developed for their own use". As an aside, if they're so neat and useful then why aren't they in the core product?

One of the more recently developed fields is the View User Property custom field, which is currently only documented in the issue that last link refers to. This handy little field allows you to display properties that you previously added to a user, as a read-only field in each issue.

For example, add a property named "Company" to some of your users in JIRA, then install the JIRA toolkit and create an instance of the View User Property field. Now configure it with "reporter:Company". Add the new field to some screens and the value of the reporter's Company field will show up in the issue. This also works with "assignee:Company". You can even get a user name with "My Custom Field:Company". This will use the user name found in the custom field named "My Custom Field". Just use the JIRA custom field name, including any spaces.

I've just used this to associate a company name with every customer user, and I'm sure there are a number of other pieces of per-user information that could be displayed with this field. One missing piece for this field is the ability to search for issues with particular values.

Evaluating JIRA Multisite

Given the number of organizations already using JIRA across a WAN, there is plenty of interest in finding ways to improve the experience. I've had a few clients suggest using distributed databases, changing HTTP caching behaviour or not using HTTPS. None of these are really great fixes, and are complicated by the fact that JIRA keeps much of its data in a local Lucene index outside the database for performance reasons.

So when WANdisco announced a beta of JIRA Multisite last November in partnership with Atlassian, I was interested to see what it would do. It's billed as a high availability solution and in doing that it gives you local JIRA servers with all your data nicely synchronized. There is another approach that was announced at about the same time, the JIRA clustering solution Scarlet. I haven't evaluated Scarlet yet but it appears to have a single point of failure by default.

I contacted WANdisco to ask for an evaluation copy and they were happy to help. They have an existing replication tool for CVS and Subversion that they've connected to JIRA. You need their tool and their instance of JIRA. As an aside, though they are keeping up with each release of JIRA, I'd rather have instructions about how to modify my existing instance of JIRA to work with their tool, but I'll take what I can get for now.

To provide high availability you have to have 3 or more instances of JIRA, but since I was mainly interested in how each sites' performance changed, I just set up two instances of JIRA, one in San Jose, CA and the other in Bangalore, India. The connection between the two sites is a clogged T1 at best and the team in India often have sluggish response times from JIRA.

Setup Experience

WANdisco wanted to set the tool up, but I did it myself in an hour for the two nodes. Instructions were beta quality, but not bad. After that piece of stubbornness, their tech founder worked out what I had done wrong in about an hour, and then together we had it all working in another hour. Three hours from scratch is pretty good as these things go.

Testing

I modified a bug in San Jose and watched the change appear in India a second or two later. Then I modified a bug in India and saw the change locally in about the same time. Just as expected. Then we stopped one of the JIRA servers, made some changes, waited a bit, restarted the server and saw the changes all get synchronized. Other users updated issues over the next month and the changes appeared just as expected. The big win was that the users in India saw their local response improve dramatically. The underlying WANdisco replication tool was rock solid for the month's evaluation.


Restrictions

The version I tested didn't synchronize attachments, but that has been added since then. You do have to use the same OS (and database I believe) for all the instances of JIRA. This was not a problem for me, but if you have a Windows server in one location and Linux in another, it won't work.

I didn't try https, but I did set up LDAP authentication and that worked as expected

I'm pretty sure that if I wanted to go back to one instance of JIRA I could have exported the data and then reimported it into a non-multisite instance of JIRA.

Cost

Pricing is public and is US $7500 per instance of JIRA, which is about 50% more than the current Enterprise license cost. This seems about right given the cost of the tool and the target customers. Support comes from WANdisco and JIRA, in that order.

Summary

JIRA Multisite is still in its early stages, but it is very promising. It worked well for me with little effort, and provides good value for the price.

Atlassian has acquired Cenqua

Which is not surprising, given how many of my customers use both Jira for bugtracking and FishEye as a front-end browser for their version control. What's funny to me is that I suggested it to Scott Farquhar, the CEO of Atlassian last month at the Silicon Valley Atlassian User Group meeting, but I didn't pick up on why he looked a bit surprised by my suggestion that "hey, y'know, Atlassian should buy those FishEye guys!". Next time, I'll just ask if he wants to play poker.

No word on the terms of the deal, but from my perspective, it's great news. Best wishes to all involved.

Useful "FishEye for Jira" plugin

Jira is easy to integrate with CVS and Subversion, but there's a FishEye for Jira plugin that can give you even better integration. If you are using FishEye (think ViewVC on steroids, plus change logs) as a front-end to your CVS or Subversion repositories, you should definitely investigate this plugin.

The screenshot below shows how the plugin replaces the Commit tab in Jira with a new FishEye tab.


Why is this a better approach?

The default mechanism used by Jira to connect issues to commits is by looking for issue identifiers in commit messages. For example, a commit with the message "Fixing TST-1234 again" is probably referring to the issue TST-1234. So far, so good.

The problem is that getting this information from CVS and tracking ongoing changes involves running "cvs log" and parsing the output. I recently came across one such file that was 90MB and took 10 minutes of churn to produce. Since the commit is only connected to the issue when this file is reparsed, there is often a sizable delay between making a commit and seeing it appear for the issue in Jira. Subversion integration with Jira is less of a load on the Subversion server, but still suffers from the same delay.

The FishEye plugin is much smarter than that. It uses the FishEye API to remotely query your FishEye instance each time that you refresh the FishEye tab of an issue inside Jira. FishEye has already indexed all the commits for its own purposes, so it can provide up-to-date results far faster than the out-of-the-box approach. Another benefit is that Jira no longer needs to load down the CVS server, or even contact the Subversion server.

Nitty Gritty

Installation is just like any other plugin, with some configuration in a .properties file. Remember to enable the API access in FishEye, and use the same names for repositories in the configuration file that you used when defining them in FishEye.

Field-level permissions in Jira

Notice how the Fix Version/s field is read-only? This is something that many people have wanted for a while with Jira. I've posted a description of how I restricted who can edit individual fields on the wiki for Atlassian Jira. It doesn't handle the case of completely hiding a field from a group of people, but It Worked For Me.

~Matt

Using Jira for Test Tracking

I'm giving a brief talk tomorrow on using Jira for Test Tracking at the first California Atlassian User Group tomorrow. More details on the user group may be found here.

(update: here are the slides and they're also attached to the Atlassian page)