I love JIRA, I really do, so long as I never have to do any administration to it.
I’ve got a JIRA instance set up as a household to-do system. Today, I tried installing JIRA 4.1 as a test instance, upgrading from version 4.0. It turns out I won’t be making that upgrade for real any time soon, as 4.1 breaks many of the plugins I need for my JIRA workflow. If I upgraded, I’d cripple my setup beyond usability.
Unfortunately, Atlassian has chosen to leave many obvious and necessary workflow actions out of JIRA, instead relying upon third-party plugins to provide them. This wouldn’t be a problem if Atlassian didn’t change their plugin API more often than Tiger Woods picks up new sexual partners.
Okay, so I figured I’d at least upgrade to version 4.0.2; I’ve been putting that off for too long. It’s anything but an easy process, especially when you’re running the EAR/WAR version instead of their “standalone” that comes with its own Tomcat instance. They don’t have a standalone build for FreeBSD, so I don’t really have a choice.
Although the process is really convoluted and something only a Java wonk could love, it wouldn’t be so bad except that JIRA’s plugin system is so horrible. JIRA plugins are generally Java .jar files. There are two kinds of JIRA plugin now, Version 1 and Version 2. It’s not obvious from looking at a plugin what kind it is. You have to either go to Atlassian’s plugin repository and find it there, and the page will tell you what version the plugin is… or you have to extract the plugin and go digging in XML files trying to find a setting that will exist only if it’s version 2.
Depending on whether it’s version 1 or version 2, the plugin has to go in one of two widely different directories. If it’s version 1, it goes in a directory that will need to be wiped out when you upgrade JIRA.
What’s so bad about that? It’s also the directory that houses dozens of JIRA’s own .jar files, and there’s no way to tell which ones are part of JIRA and which ones are plugins. In fact, there’s no way to tell what plugins you’ve installed short of doing a file-by-file comparison with a clean JIRA installation of the same version.
Better document that JIRA installation really well as you do it…!
It gets better! Some Version 2 plugins won’t work from their new, plugins-only directory anyway! You won’t find this out until they fail to work, and then you dig through the log file—which Atlassian so thoughtfully creates in whatever working directory you happened to be when you started Tomcat—and see a message that you have to copy the file to the old directory!
Of course, if you merely copy the file, as directed by the error message, you’ll get another warning that there are two copies installed so you can’t use either…
Did I mention that every time you add or remove a plugin, you have to restart Tomcat? If you don’t have some really rockin’ hardware running your JIRA instance, that’ll bring you a minute or two of downtime. It’s annoying with three users in one household; it’d be a bloody outrage if I were supporting a large company with this.
What’s particularly galling is that Atlassian’s other major product, Confluence, does plugins so well. You can search the Confluence plugin repository from within your Confluence instance’s administration screens. You can see which plugins you’ve installed, and if they’re out of date Confluence will tell you so and offer you a link to download and install the latest version. There’s even a web-upload link to install .jar files from outside of the Atlassian repository. Atlassian knows how to do this right. They just haven’t bothered with JIRA.
So, I do my upgrade. This entails backing up the current JIRA instance to XML, creating a new database for the new JIRA, installing the new JIRA instance, copying over a number of settings files, tweaking my Tomcat settings, copying over plugins I’d backed up previously, restarting a few times to get the database loaded and the plugins in place, etc. etc. …
…and then the bloody thing doesn’t show any of my workflow actions, because I’m one plugin short. It doesn’t even clearly tell me “hey, you have workflow actions that don’t seem to be defined” anyplace useful. It just doesn’t show me any workflow actions. When I go into my workflow editor, the only clue is that some workflow actions look like
Type: class Class: com.googlecode.jsu.workflow.function.UpdateIssueCustomFieldPostFunction Arguments: field.value = Yes field.name = customfield_10040
The Needs Parts of the issue will be set to Yes.
Notice how there’s also no hint whatsoever as to which plugin you previously had that’s now AWOL; you’re left to figure that out on your own.
After finally figuring out which plugin was missing—the one that implements the ability to change the value of a field other than the default ones provided with a generic JIRA install—installing it, starting, finding no improvement, finding the log error saying it’s in the wrong place, moving it, restarting… I finally have my workflow actions back, and I’m an hour behind on my other tasks for the day.
Then there’s the security patch. The boys at Atlassian had a rather embarrassing security breach recently. It highlighted a number of XSS attacks against JIRA. None of the code currently available for download includes the fixes, so you have to apply the patch. For EAR/WAR installs like mine, this involves:
- Extracting the patch files on top of the source for JIRA
- Rebuilding the WAR file
- Stopping Tomcat
- Copying the WAR file into place
- Backing up your existing Version 1 plugins, which Atlassian doesn’t bother to mention in the instructions, so hopefully you understand this consequence of what they do tell you
- Deleting the Tomcat work directory, because otherwise Tomcat may cache the old .jar files
- Creating a new Tomcat work directory by hand, which Atlassian doesn’t mention; if you don’t, Tomcat will appear to start but won’t actually run anything…
- Deleting the old jira directory, because otherwise Tomcat may not unpack the new .jar files, which isn’t mentioned in the patch directions but is mentioned in a troubleshooting section under new installs for when you upgrade and find upon restart that you haven’t, in fact, successfully upgraded
- Starting Tomcat
- Waiting for Tomcat to start JIRA
- Stopping Tomcat
- Reinstalling the Version 1 plugins
- Starting Tomcat
That’s one of the more convoluted “security patch” procedures I’ve ever had to deal with in over 15 years as a professional UNIX systems administrator.
If you’re thinking of buying JIRA for your business: If you can’t afford to hire a Java guru to be your full-time JIRA guy, don’t bother. You will need someone who understands Java and databases and Apache Tomcat and your choice of operating system, and they’ll have their hands full.