Migrating Jira configuration from development to test to production

[Steinar Bang]

I would like to automate the migration of configuration changes from the Jira instance used for development (of Jira configuration changes, extensions etc.) to the Jira instance used to test the Jira changes, and finally deploy the changes to the production Jira.

Does anyone have experience, they would like to share, with any of the methods listed below? Does anyone have experience they would like to share with methods not listed below...? :-)

The particular question I would like to have answered, is: how do you handle changes in configurations between the different environments? The changes I need to do when moving configurations, are primarily the changing URLs to Confluence, Jenkins and Stash.

I have found these Jira plugins that both seem to be targeted to this use case:

• Project Configurator
  • Issue: not possible to map certain changes in the configuration (e.g. different URLs for Confluence, Jenkins, stash) for the different environments developmet, test and production
• Configuration Manager for Jira
  • Issue: the synced projects need to be manually created before they can be synced by the plugin

Other possibilities are:

• Use the XML export/import and strip out all of the issues
  • Question: will a re-import overwrite existing settings or create new items with the same name?
  • Question: will stripping the data cause the data (i.e. the issues) to be deleted in the target system?
• Use the new JSON export/importand strip out of all of the issues
  • Wasn't complete the last time I looked at it (it's still in beta)
  • Has the same questions attached to it that the XML export/import has
• Use the REST API
  • I know the REST API can do everything I want to do
  • Writing a syncroniztion tool that uses the REST API will be a lot of work

[Boris Georgiev [Appfire]]

Hi Steinar,

Regarding Configuration Manager for JIRA - You need to create projects only if you use the project snapshot deployment functionality and if you use system snapshot deployment then everything is created automatically (also, creating the synced projects when doing project snapshot deployment is a feature that we'll release soon).

Another important issue you might experience with the other methods you've listed is the automatic migration of issues when there are "incompatible" configuration changes like:

• When you change the workflow scheme of a project and the new workflow(s) is missing a status(step) that was present in the "old" workflow then all existing issues in the project need to be updated to point to a new status (step)
• When a workflow step is removed - a new step should be specified, so all issues are properly updated
• When a security level is removed from an issue security scheme - all issues currenlty using this security level need to be migrated, so wither the security level is removed or a new one is assigned, otherwise these issues will not be visible to anyone (including administators)
• When a version or component is removed from a project - this also includes migration of issues

Configuration Manager for JIRA handles all described above, by providing migration UI for configuring how the migration should be appled and then updates all the issues accordingly on deployment.

One of the main scenarios that Configuration Manager for JIRA is targeted to is automating the Dev-Staging-Prouction deployment/migration process, so we'll be happy to make you a demo of the plugin and discuss your specific needs and also hear some feedback from you as it seems you've evaluated our product.

If you're interested just drop a mail to support@botronsoft.com.

[Steinar Bang]

Hi, thanks for your swift response!

Do you handle environment config changes? E.g. a different Confluence, Jenkins, Stash etc. for each of the environments for dev, staging and prod?

Or is this handled implicitly by manually setting these URLs in each of the environments, and then excluding the URL differences from the upgrade? If so: is that exclusion persisted so that it won't be presented as a diff on each config migration?