Best practices for transferring configuration between JIRAs

[David Toussaint [Communardo]]

Hi folks,

just now I came across a situation where I'm not sure of what is the best approach. So I wanted to ask you guys how you are handling this. Here we go:

We have three (!) JIRA systems running, on productive system, one test system and one development system. Usually for any major configuration changes we do the following:

1. "develop" settings and configuration that words on, done on development system
2. document this
3. ask our admins to use the documentation in order to apply the modifications to configure the test environment as the documentation says (two purposes: check the validity of the documentation and educate our admins)
4. check the test environment if all was configured correctly, (let other users test this)
5. modify the documentation and/or settings, if needed
6. ask our admins to use the documentation in order to apply the modifications to configure the productive environment as the documentation says
7. test on production environment if anything is missing
8. being done.

In order for this to work out the three systems are basically identical, settings are "synced" (manually, beloved admins) every now and then. There may be minor inconsistency but that should rather be an exemption.

Now I have configured a super complex workflow and everyone is happy and pushing hard for it to go live in the production system. So I thought I'd be clever, configuring screens, issue types and fields, installing needed plugins (it's all done already) and then only export the workflows as XML and reimport it on the productive system.

NOPE.

While doing this I just learned that all status' and screens and steps and stuff is called by its ID in the XML. While I can imagine possible backgrounds of this it basically means I have no chance (ok, 0,001% chance maybe) of using this export/import interface for transferring the workflow as the is a 99,999% chance of either a status, screen or step is having a different ID in one of the systems.

Is there any way you guys cope with such scenarios?

Oh, in case someone is suggesting the workflow sharing plugin, to me this thing is a complete mess. Inserts new statuses (bad mapping), cannot handle special characters (ä, ö, ü, ß - I’m in Germany...) and so on. Tried this already. I'm on JIRA 5.0.6 (both systems)

Thanks a lot, let’s have a fruitful discussion :)

David

[abed · Accepted solution]

Hi

for the Workflows/screens changes i usually apply it on the production server and test it on a seperate jira project

if every thing was ok i apply it back to the rest of the projects

i only use the test system when planning upgrade or instllation new plugins

unfortunately in your case you need to create the screens, statuses and workflow again on the production server

or create the statuses/screens in the same order when you create them on the test server, the IDs are incremental, check them from the test site, then do the workflow import (it's gonna take the same time though "creating them from scratch" :P)

regards

[David Toussaint [Communardo]]

actually not the answer I wanted to hear, but thanks anyway. I went the tough way this morning and reconfiguring all this on the production system.

[Bob Swift OSS (Bob Swift Atlassian Apps)]

JIRA Command Line Interface has an exportData action that can help with some of the project data, but not the workflow related stuff :(.

[murali krishna]

Try this solution: https://answers.atlassian.com/questions/133739/can-i-copy-project-settings

This worked for me.

[Scott McCormick]

I had the same question as you and didn't find a suitable solution available, so we made our own.

We put together a perl script to promote configuration data (workflows, screens, fields, groovy scripts, etc.) from our Dev to Prod JIRA instance. Our method was to copy all the configuration database tables from the Dev to Prod JIRA DB.

Due to some issues with MS SQL Server, we transferred the workflows via XML export/import.

It has been working fine for 5 or 6 months...

You can see some details here:

https://answers.atlassian.com/questions/30526/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

[Radu Dumitriu]

Try this: https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-workflow-sharing-plugin

Interesting enough, prior to that we had internally a tool we called Sunda-to-Sahul (read here why: http://en.wikipedia.org/wiki/Sahul_Shelf or http://en.wikipedia.org/wiki/Sunda_Shelf ) Anyway, it never reached production code quality so we could release it. It worked on creating deltas between two Jira exports ... That plugin above ended the development on our side.

[David Toussaint [Communardo]]

Well, as stated above the workflow sharing plugin does not work for us due to several restrictions. And the result is not desireable IMHO.

Thanks for pointing out though.

[Radu Dumitriu]

Ah, I missed that ! (sorry for that)

Edit: Anyway, if you have problems, you should raise bugs on it. Otherwise it wont get any better ...

[Dieter]

This was a solution once for Jira 3: https://marketplace.atlassian.com/plugins/com.bosch.jira.plugin.deployer/version/100 It's punlic and of course everyone can start it's own development based on the code. The code is tremendously complex but this just reflects he complexity of Jira scheme and custom field concept ...