PCJ:How to Split an Import into Separate Stages
- Camilo Galleguillos
If your configuration is very large, it may be more convenient to spit the import into several shorter stages.
The import is split by selecting different object types to be ignored or skipped each time. The selection of object types to skip in each stage must take into account the dependencies that may exist between different object types. For example, workflow schemes link issue types with workflows, so it makes sense to import issue types and workflows before workflow schemes. To help you identify where objects are used in your instance, you can run the Object Dependencies report.
Dependencies
Dependencies include workflow conditions, validators, and post-functions used, including those defined in supported workflow apps.
For a given configuration, you cannot import one of the object types in the first column in the table below if the object types in the second column have not already been imported. Consider also that the requirement is for the referenced object to exist in the target instance. It is not necessary that it has the exact configuration as defined in the XML file.
Projects included in the XML configuration file are always created with a default configuration, including default schemes, therefore you cannot skip the creation of new projects.
Object Type | Requires |
---|---|
Workflows | Statuses Screens Event types Issue link types (1) Issue types (1) Custom fields (1) Project roles (1) Priorities (1) Resolutions (1) |
Workflow schemes | Issue types Workflows |
Versions | |
Users | |
Statuses | |
Screens | Custom fields |
Screen schemes | Screens |
Role members | Users Groups |
Resolutions | |
Projects (changes)Â | Categories Issue type schemes Field configuration schemes Workflow schemes Permission schemes Notification schemes Issue security schemes Issue type screen schemes |
Project roles | Users Groups |
Priorities | |
Permission schemes | Users Groups Project roles Custom fields |
Notification schemes | Users Groups Project roles Custom fields |
Issue types | |
Issue type screen schemes | Issue types Screen schemes |
Issue type schemes | Issue types |
Issue security schemes | Users Groups Project roles Custom fields |
Issue link types | |
Groups | Users |
Filters | Groups Project roles Projects |
Field configurations | Custom fields |
Field configuration schemes | Field configurations |
Event types | |
Dashboards | Groups Project roles Projects Filters Custom fields |
Custom fields | Issue types Projects |
Components | |
Categories |
Step-by-step Guide
- Decide which object types will be imported first.Â
- For your first stage, start skipping "Projects (changes)".
- Select which other object types you want to skip. It is a good idea to start with those included in the cell to the right of "Projects (changes)" See Selecting Import Options for more information on skipping object types.
- Once you decide to skip an object type, you can decide to ignore other object types which the first depends on. Check that they are not needed somewhere else.
- Decide if more partial imports will be needed. After running a first partial import, you may decide to run other partial imports. As the project configuration upload page keeps your previous selection of object types to be skipped, you only have to deselect some of those object types, to have them imported in a new stage. Start by deselecting those object types with all their dependencies previously loaded. It does not matter if you ask the app to re-import object types that had been loaded in the previous stage. The app will detect that configuration items loaded in previous import stages are already configured in the target instance and only perform operations on the remaining object types.
- Run the last import stage. For the last import stage, simply select a full import (i.e. skipping no object type).
It is recommended that you test the import on a test instance to verify that the split files import as expected.
Related Articles
-
Page:
-
Page: