JIRA preliminary plan for project import-export

Added by Brett Jackson, last edited by Mark Lassau on Jun 18, 2008  (view change)

This is a summary of what is and isn't included in the project import/export feature for JIRA 4.0
Note. Some element's inclusion/exclusion may change during the development process.

Included

  • Project - Name, Key, URL, Lead, Description, Default Assignee
    • Versions - Name, Description, Release Date (order)
    • Component - Name, Description, Lead, Default Assignee
    • Roles - names and membership information
  • Issues - Including system and custom field values
    • Comments
    • Worklogs
    • Issue Links - including links to other projects where they exist.
    • Change History - the history of changes to each issue
    • Attachments - optional
      Importing fields will check that those same custom fields exist when restoring project data, and that the custom field versions are identical.
      If a custom field plugin is missing, then a warning will be shown, but the import can continue by ignoring that data.
      Third party custom fields written against JIRA v3.12 will need to be updated in order to support project import.
      (The old custom field will be compatible with other JIRA functions, but will induce a warning on the Project Import that the data will be ignored.)
  • Users - ie full names and emails
    • Users which are referred to in the imported project, but don't currently exist in the target JIRA, will be imported when possible.
      • External user management in the source JIRA may mean that not enough information is known to add these users.
      • External user management in the target JIRA will obviously mean that it is the external users management system that requires the new users. JIRA will be able to supply an XML export of required users.

Excluded

  • Groups - including group names and membership information
  • Workflow - users will need to manually ensure the exact same workflow exists on the remote system, if needed. The statuses will be mapped to the workflow that exists on the remote system (existing XML workflow export/import should work here)
  • Custom Field Configuration - Field contexts (which project/issue types field applies to), options, values and defaults
  • Project Categories - Need to re-connect categories on the remote server
  • Project "Connections" - Screens, permission / notification / issue type / issue level security / workflow / screen / field configuration schemes, field configurations, CVS/SVN/P4 repository details

When importing, a user will need to re-connect a project to new schemes and related entities.

The restore will only allow to restore the project into the exact same JIRA version. If one needs to restore into a newer instance of JIRA, they will need to setup a test instance of JIRA which matches the version of the exported data, import project data there, upgrade the test instance to desired version, do another project export, and import the new exported data into the live instance. This is exactly how Confluence's Space Import/Export works at the moment.

Labels

 

Comments (12)

 

  1. Oct 10, 2007

    Michal says:

    Hi\! The problem we met when we added new projects to existing JIRA instance is ...

    Hi!

    The problem we met when we added new projects to existing JIRA instance is that we need to implement some new functionality, including customized workflow, screens and custom fields. The new configuration should be tested before promoting to existing, production JIRA instance. The solution for this problem can be the functionality of cloning existing configuration (it can be done now), but lets say all the issues, only configuration, made changes, tests, fixes, until every tests success, and then backporting only added configuration. If we assume there was no changes in configuration since 'clone' operation, the newly added configuration should be easy to merge with original one.

    Approach described in preliminary plan is only the issue-side import/export solution, which does not solve above problem at all and look rather minimalistic. It is easier to duplicate user form-entries and overwrite original timestamps to restore all the project history than import/export the structure of the data.

    There is a long time we waited for import/export project solution but it looks like you are a little scared of difficult work which have to be done with it. Sorry for the rough words, you did a great job, but we expecting to continuous it!

    Regards

    1. Oct 11, 2007

      Stefan Kleineikenscheidt says:

      I stronly second Michal's view on this issue. At the moment we have started work...

      I stronly second Michal's view on this issue. At the moment we have started working on a solution for importing/exporting (a plugin) configuration internally. What we do is:

      1. On the source JIRA instance, we read a project and all its associated schemes and export the that to XML.
      2. On the destination JIRA instance, it the XML is read and imported. (Actually, we do a verification of the data before we import, as a roll-back is not possible).

      Issues we came across:

      • The configuration artifacts on source and destination JIRA instance do not have the same internal IDs (e.g. '10021'). Therefore we have to use the names of the artifacts which may not be unique - for example, there may be multiple custom fields with the same name.
      • The source and the destination JIRA should be identical in terms of plugins, etc.

      Please let me know, what you think about that approach and whether it would suit your needs.

      Btw: I am currently talking to senior management about opensourcing this plugin. If you would be interested, please email me (stefan dot kleineikenscheidt at de dot bosch dot com).

  2. Oct 11, 2007

    Eugene Gavrilov says:

    We are using Jelly scripts for configuration migration in some cases. It can be ...

    We are using Jelly scripts for configuration migration in some cases.
    It can be the way to export/import configuration with some manual modifications if required.
    Proposal scenario:

    1. Export configuration to Jelly script in JIRA (could be a separate page, or "export" link on each entity like "*Schema")
    2. Modify the script if required (It's should be readable)
    3. Run the script on another instance of JIRA.

    So it's not a truly import/export, but would be helpful and all possible schema conflicts goes to administrator that performs the script execution.

    1. Jan 10

      Michal says:

      Eugene  Is there any option to export configuration into Jelly Scripts?

      Eugene

       Is there any option to export configuration into Jelly Scripts?

  3. Jan 10

    Michal says:

    Hi\! Once again I'm back to this thread. What is the goal are you, Atlassian Guy...

    Hi!

    Once again I'm back to this thread. What is the goal are you, Atlassian Guys trying to achieve by this proposed functionality? I can't imagine for what it will be useful. Are you going to move project between two identical instances of JIRA?

    Stefan, have you developed or know some usable piece of code to maintain test to live production environment migration?

    Regards 

    1. Jan 10

      Stefan Kleineikenscheidt says:

      Michal, we are still working on this plugin. Also, we still need to get the appr...

      Michal, we are still working on this plugin. Also, we still need to get the approval of our senior management to opensource the plugin.

      I will let you know, when we are ready to release something.

      -Stefan

    2. Jan 16

      Anton Mazkovoi says:

      Hi Michal, The goal we are trying to accomplish is not moving test configuratio...

      Hi Michal,

      The goal we are trying to accomplish is not moving test configuration to production environments. The goals are:

      1. Allow to move a project from one live JIRA instance to another live JIRA instance to facilitate splitting and merging of JIRA instances.
      2. Allow to restore a single project from a backup, e.g. if the project has been backed up for archival purposes and deleted, but is needed again in a live system, or if a project has been deleted by mistake.

      Accomplishing the above tasks often involves developing custom tools such as the ones described in our documentation:
      Merging 2 JIRA instances
      To do this you will need a developer.

      We are hoping that after the functionality described in this document is added, these goals can be accomplished without having to develop custom tools. While setting up the required configuration in the system where the project will be restored could still take time, it can be accomplished by administrators without involving developers.

      Cheers,
      Anton

  4. Jan 17

    Owen Carter says:

    I need to add my $0.02 here, preserving the change history is critical I honestl...

    I need to add my $0.02 here, preserving the change history is critical I honestly do not think you should be considering omitting it. Even if you have to drop or reformat some of the data (usernames for instance, I appreciate they are not being exported, but you could just leave the plain-text username in there). The ability to know who changed the issue, and when they did it, is critical for any organisation that might have to account for their decisions. Imagine if we were unable to tell our customers whether it was them or us who changed the priority of a security issue from 'Blocker' to 'Minor' when they query why we failed to fix it.

    1. Jan 22

      Anton Mazkovoi says:

      Hi Owen, I see what you mean. We definitely realise that change history is impo...

      Hi Owen,

      I see what you mean. We definitely realise that change history is important.

      At the moment we are trying to do our best to preserve it. However, as we have only started to work on this feature we are not sure about what roadblocks we are going to hit. We will do our best to work through them.

      Cheers,
      Anton

      1. Mar 27

        Joel D. Tecson says:

        Hi Owen, Our company currently evaluating JIRA 3.11 Enterprise Edition, we were ...

        Hi Owen,

        Our company currently evaluating JIRA 3.11 Enterprise Edition, we were using MS SQL Server as a backend for the application. As of now Im creating a tools and query to migrate individual project together with the comments, attachments, worklogs, issue links etc... since we were planning to move to production soon.The problem I encounter right now is the History. I cant figure out where the application store the data in history, please help me.

        Thanks,

        Joel

        1. Mar 27

          Anton Mazkovoi says:

          Hi Joel, For more information on how Change History is stored please see:

          Hi Joel,

          For more information on how Change History is stored please see:
          http://confluence.atlassian.com/display/JIRA/Database+Schema#DatabaseSchema-ChangeHistory

          Cheers,
          Anton

    2. Jun 18

      Mark Lassau says:

      Good news the Change History will now be included. I have updated the page to re...

      Good news - the Change History will now be included.

      I have updated the page to reflect the current design. The other significant inclusions are automatic import of required users, and adding Project roles with membership.