How to keep configuration changes between upgrades of Atlassian products?

Question

It seems that if you are using Atlassian products for more than just fun (with lots of teams and products) you are forced to have to modify files in the installation directory, like adding some jar files, or modifying different configuration files (properties or xml ones).

I am looking for a way that would be similar to using patch queues for applying these changes again on a new version. I do not have the time to manually cherry pick the changes each times, especially that each products does have about a dozen of releases each year.

So far I was using a home grown upgrade script that was keeping the modified files on upgrades, but the number of exceptions started to grow and I am sure that sooner of later I will end-up with missing some new changes on one of these files.

Due to this I suspect that something following the model of a patch queue would be more suitable in this case.

Is anyone using something like this successfully?

Sorin Sbarnea ( · Answer

I am not talking about source code changes, let me give you few examples: context.xml, server.xml, setenv.sh, log4j.properties, catalina.properties, jira-application.properties, some added jar files or footer.jsp, head-common.jsp, jpm.xml -- last one needing patching if you want to speedup indexing see https://jira.atlassian.com/browse/JRA-38598

All the changes are minor, like changing a parameter or adding a line, probably the perfect use-case for using patches. My question was if anyone was using such a solution and which one they picked.

Joe Pitt · Answer

Not sure what you mean by 'more than just fun'. I've configured JIRA for use with multiple projects, issue types, workflows, screen schemes, etc. without using anything more than the jira-suite utilities plug in. As a COTS product modifications to code should be kept to a minimum and it is a given most users will have to make some concessions to their desired behavior of a tracking tool. If you are heavily modifying the source code it may not be the solution for you. Since you can never be sure if the vendor will change the source code you've modified with a release you need to check each time you upgrade to see if your modification will still work. I spent over 20 years supporting IBM mainframe systems and we gradually reduced our user modifications because of the time it spent to refit them, sometimes up to a year. I suggest you revisit your modifications and see if the are 'nice to have' or required for how you MUST do business, not how you would like to do business.