Upgrade without manual (re)placement of customized JSPs/Templates/Plugins, etc

So,

Once upon a time, I came across the JIRA footer at an open source project. I clicked through and played around. And it was good. To say the least. I learned some of the ins and outs and eventually was able to leverage that knowledge thanks to my fabulous company purchasing an Enterprise license and adopting it within EVERY department. I'm so excited that our Marketing people are using the word "ticket" outside of a concert venue.

Sadly, I'm not a *nix ninja. I might be that white belt in the corner, quivering in a pool of his own... output... But who can, when nobody's putting a lot of pressure on him, put up a decent enough fight.

As my organization and I have grown with JIRA, I've found myself with the cross hairs of many a UNIX admin on my face due to my attempt at scripting a file that basically accomodates my workflow as follows:

Directory Structure

• /var/www/jira/ symlinks to /var/www/alljiras/jira3121 or whatever's newest
• I have a structure set up in /var/www/jira/alljiras/common that contains lovely things like
  • A directory of custom images (not at all to imply Atlassian's selection of graphical representations are anything but fabulous)
  • A custom directory of email templates and the accompanying mappings file.
  • A bunch of plugins to be dumped in WEB-INF/lib and their corresponding (configured) properties files to be dumped in WEB-INF/classes
• Some other files that need to be overwritten (such as within secure or other JSPs)
• A list of morally objectionable newsgroup archives detailing how individuals of all types may pass their time using three vegetables, a bottle of Dr. Pepper and 3 sticks of gum

Actually using it

So, I have a common directory that has files I know and love, and I'm all for symlinking (after telling tomcat in its server.xml file that I'm OK with that). So, here I sit, with a fresly-untarred version of JIRA 3.12.1 in /var/www/jira/alljiras/jira3121 and a quasi-proprietary but arguably-logical organization of files in /var/www/jira/alljiras/common. Now, since I'm really giving my ln -s skills a run for their money, I've devised a script to go through and replace some of the more custom aspects of my configuration, such as:

• Symlinking my own email directory to WEB-INF/classes/templates/email as well as the email-template-id-mappings-or-whatever.xml file.
• Adding my own (aforementioned) spiffy images directory
• A few other visual tweaks on files that exist
• Overwriting (to the dismay of every Computer Science professor EVER) the config XML files (such as web, server, jira-application.properties, etc. etc.) with these "common" files.
  • Crossing my fingers that you crazy Atlassian folks didn't completely redesign the schema and cause life as we know it to vanish in a puff of logic.
• Copying all the plugins to the appropriate lib directories
  • ...and their config files in their appropriate directoes.

Making it less homicidally awful...

Now, several thoughts crossed my mind in this implementation,

1. Maybe I could just overrwrite the files after doing some sort of visual confirmation or diff that the destination files are, by-and-large unchanged. *(This is what i sort of do, via removing, copying/symlinking, etc)
2. If I was really fancy, maybe I could do something with diff and patch or some other text editing tool, based on the complexity of the file I wanted to grab.
3. Hiring an intern, with his only job description being the management of our (arguably VERY customized) JIRA configuration and bringing me exotic coffee beans from occasion, along with three indigenous birds from their respective regions.

Sadly, interns aren't all they're cracked up to be, and I think that a good investment of time to support enterprises who really customize JIRA up the wazoo (sorry for the coarse language) would be to have a "patch" system similar to your external-src directory.

If files can be {{patch}}ed somewhat intelligently (and you had bells, whistles and other epilepsy-inducing UI elements notifying users of a major change that would require a re-write) using an automated system, that'd be great.

I mean, even if we could set up a *common* JIRA directory structure with just the files that we changed (bonus points for making a script that would run and determine these changed files and send them to this *common* directory store), that would be a great first step.

And if we could have your talented team of developers come up with a way to generate patch-y esque {{diff}}s from this structure that could be injected into future JIRA instances, that'd be great too.

Of course, If I was Billy Bugfiler who had nothing better to do than whine about implementations at present, I'd suggest a slightly more modular approach to customizing templates and having them persist through version upgrades. Or maybe having more configuration items captured in the XML backup/restore procedure.

The point of all this babble...

To summarize, it'd be swell if there could be some developments made as a part of JIRA or as a "plug in" that would permit users who heavily customize various aspects of their configuration to retain these changes through upgrades (within – of course – valid upgrade versions that don't employ completely new logic) and to apply this logic to brand-new installs. Even if you just provide a "makeJIRAPatchFile" and "applyJIRAPatchFile" scripts with some Atlassian Magic and leave us XML-fiddlers on our own to make our own scripts using these resources, I think it would be a great help and would assist in rapid adoption of your new (and much appreciated/anticipated/kick-ass) releases.

Thanks, ladies + gents!

–
Tim Feeley // MANHUNT Product Manager
Online Buddies, Inc // tfeeley@online-buddies.com