/
Single-Project Snapshots

Single-Project Snapshots

On this page:

Deploying Single-Project Snapshots

Single-project snapshots are project snapshots that contain the configuration of only one project. Read our Multi-Project Snapshots document if you want to deploy a snapshot with more than one project.

The deployment of single-project snapshots starts with providing a deployment snapshot on CMJ’s Deploy page. After that, the deployment goes through the following phases:

  1. Select phase - In this phase, you must choose a deployment mode: Merge Project or New Project.

  2. Analyze phase - In this phase, CMJ performs deep change and impact analysis of the changes that the deployed snapshot will introduce on the target Jira instance.

  3. Migrate phase - This is the issue migration phase. It’s only required when issues on the target Jira are incompatible with the snapshot configuration. To learn more, see the list of cases that require Issue Migration.

  4. Deploy phase - This is the final phase of the deployment process. In this phase, you must confirm that you want to apply the configuration and issues from the selected snapshot to your Jira instance.

This document will walk you through the initial Select phase of the deployment. Choosing between Merge Project and New Project mode is important because each mode represents a different deployment strategy. Read below to understand what will happen with your project configuration and issue data (if your project snapshot contains such) in each deployment mode.

Merge Project Mode

In Merge Project Mode, you can deploy:

  • project configuration snapshots - they contain only the project’s configuration, or

  • project with issues snapshots - a project configuration together with issue data.

Merging the project configuration works the same way in both cases, but merging issue data has its specifics. Read more below.

Merge Project Configuration Snapshot

When you deploy a snapshot in Merge Project mode, CMJ applies the project configuration in the snapshot to the target project you choose. When merging project configurations, CMJ applies the following rules to the target Jira project:

  • All configuration objects from the snapshot that don't exist on the target project will be added.

  • If a snapshot and a target configuration object have the same name/id, CMJ compares both objects. If they are different, the app will replace the target object with the object from the snapshot.

  • CMJ doesn't delete or change configuration objects in the target project if they don’t exist in the snapshot. An exclusion: the configuration object will be deleted if it is a non-root (child) object.

Merging root vs. non-root configuration objects

CMJ applies different rules when merging root and non-root configuration objects. A configuration object represents a piece of Jira configuration. There are two types of configuration objects: root and non-root (also known as child). For example, workflows are root objects, and custom field contexts are non-root objects. You can find a full list of root and non-root configuration objects in the What is a Configuration Object document.

Example

Let's assume you have the following:

  1. workflow scheme called "Dev Code" is an example of a root configuration object.

  2. The Jira Service Management request types "A," "B," and "C" as examples of non-root (child) objects.

Suppose you're performing a deployment, and these objects will be merged into the target project. Check the table below to see if and how CMJ will change the target workflow scheme and request types in each use case.

Configuration object

In the snapshot

In the target project

Result

Configuration object

In the snapshot

In the target project

Result