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:
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.
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 :)
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)
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.
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:
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG