Is there a method to promote configuration settings (custom fields, schemes, etc.) from a Test instance to a Production instance without overwriting Production user data ?

[Scott McCormick]

I have a Production Jira instance that is used heavily and a Test instance that I can add new fields and change without impacting users. Both are version: 3.13.5. Before any development is done on the Test instance we will backup the Production instance to the Test instance. After our new fields and screens are tested out on the Test instance, we would like to import those configuration changes to the Production instance without losing any user data entered since the last backup. (We are particularly interested in being able to import custom fields.)

I have seen a similar question regarding this on the forums, but the solution was to import on a project-by-project basis. If we import a project from Test to Production won't we lose issue data updates (since the last backup) for that project? Is there a way to avoid this?

Is it possible to accomplish this by importing the Jira DB configuration tables (customfield, fieldlayout, etc.) and leave the data tables (jiraissues, etc.) untouched?

I have attempted to do this with a perl script. It does an XML backup just in case, then bulk copies the config tables (to txt files and imports them into truncated tables) and updates the SEQUENCE_VALUE_ITEM table with new IDs as required. Jira is stopped before the script and restarted afterwards. So far my testing has been only on the Test instance, as I am not totally confident this method will work...and I'd prefer not to have to restore the Production system from a backup after corrupting it. After running this script on my Test instance, when I click on an issue I get a System error "Cause: java.lang.NullPointerException". Do I need to re-index the DB or something else? Or am I trying to do the impossible?

Thank you in advance for your help!

[Scott McCormick · Accepted solution]

When I started this project there wasn't any existing solution available that met our needs. The custom coded promotion utility I created has worked well for us for over a year and we are updating it to work with newer versions of JIRA. The advantage of this solution is that we can tailor it to our needs. Also, there is now a for-purchase add-on that appears to provide some similar functionality.

[Petar Petrov (Appfire)]

Hi,

We have just released a new add-on that solves the problem of promoting your configuration changes accross different instances of JIRA. You can check it out here: https://marketplace.atlassian.com/plugins/com.botronsoft.jira.configurationmanager

[Jobin Kuruvilla [Adaptavist]]

We used Selenium with one of the customer and it went well except when the configurations where a bit too much for Selenium to handle. And the scary stuff was when one script fails due to whatever reason and the subsequent scripts are dependant on that! That was rare ofcourse with proper testing in place.

It was also a tedious job for developers because they had to write the Selenium scripts also for any changes they make and then test it again in a copy of production but support teams were indeed very happy.

[Scott McCormick]

Thanks for the feedback Jamie and Jobin. Sorry for the late response! The Selenium approach sounds intruiging, I am using that in another project and so far it has been a very useful tool.

Since I was already rather invested in using the perl script, I continued onward and found some additional tables (esp. nodeassociation) that I needed to include when copying from one instance to another. I think that was causing my NullPointerException error. There are 50 tables (I'm on ver. 3.13.5) I include when I promote from Development to Production. This includes all screens, projects, fields, configurations but excludes issue data, attachments, users, and other "user type" data.

In order to promote some parts of JIRA, I couldn't just copy the table over (ex. workflows, dashboard config).

I ended up having to dump the workflows to XML and pull them in through the GUI due to issues with MS SQL Server and our Linux server. (I would've preferred a MySQL DB...but I inherited this setup.)

So that means I excluded jiraworkflows (and jiradraftworkflows) in the table copying.

Some manipulation of the SEQUENCE_VALUE_ITEM table was needed to keep the next available id accurate. (Jira online documentation on the database schema helped here...but I wished there was more info.)

Similarly, I needed to update the project table with the newest pcounter values to insure that new issues always had a larger number (and lower pkey numbers for deleted issues were not backfilled).

Also I needed to copy files such as groovy scripts, images, .vm files, .jar plugins, some property files.

As you can tell, this was by no means an easy task...

We have used this perl script to promote our changes from dev. JIRA to prod. JIRA several times already with a few revisions to the script along the way. (In general we are very happy with it.)

[Scott McCormick]

I have had to exclude some tables from the original list of those that are promoted from dev. to prod. For example, the qrtz_* tables contain e-mail scheduling for filter subscriptions that the user can set. Also, columnlayout* holds user issue navigation column configs. Another one is sharepermissions, it holds the share level for portals and user-defined search filters.

There are a few tables I am not sure if I should include because they are empty in our setup:external_entities & jiraperms

Does anyone know what these tables are for?

Thanks

[JamieA]

In theory what you are doing is possible, but a little bit fraught, and I guess you have run into problems already.

This was a promising plugin: https://plugins.atlassian.com/plugin/details/5115?versionId=11213 - but is discontinued, or support seems to stop at jira 3.13.5.

In the organisations I've worked in the support teams who do this configuration generally go through several phases.

First, they do the configuration in UAT, and make a note of what they have done, then repeat that in production. That's boring and error-prone so they give up with that.

Next they do the changes directly in production - you should make sure that no one except admins have access to the project while it's being set up.

Another approach is to do your configuration programatically - eg with groovy scripts. Then it's just a case of running the same script on production once you are happy with UAT. Creating projects and custom fields is not too hard with the API, and at least you get a consistent approach. Right now though we just do stuff direct in production, as I say.