Expand
| Table of Contents | ||||
|---|---|---|---|---|
|
Scenario
You are a Jira administrator and get a configuration change request by a stakeholder to add a new workflow, add new custom fields, change screens, etc. You’ve created and tested these configuration changes on a Test or development Jira instance.
...
This section presents and illustrates key points and elements of the Test-Staging-Production use case.
Duration | Setup | Snapshot type | Deployment mode | Automation |
 < 10 minutes |  3 Jira Servers |  Project Snapshot |
 Project Merge Mode |  REST API Support |
| Info |
|---|
Duration in the tableincludes only the time needed to create and deploy the CMJ snapshots. The setup of the Jira servers is not included in that time interval. If you wish to understand more about snapshot types and deployment modes, please review Configuration Manager’s terminology and usage guides. |
3 Servers are required: Test, Staging, and Production Jira instances. The Staging server should be an identical or close replica of the Production server.
Make sure the same version of CMJ is installed on all instances. If not, the version on the staging and production instances should be more recent than the test instance.
You need one paid CMJ license for the production Jira instance and two free developer CMJ licenses for the test and Staging Jira instances.
Make sure CMJ supports the Jira configuration objects you would like to configure. Supported objects and integrated apps are listed in our Support Matrix and List of Integrated Apps articles.
Any apps used to configure objects in the test instance must also be installed on the staging and production instances, ensuring the app versions are the same.
It is suggested best practice that your Jira versions of the test, staging, and production instances be the same.
CMJ loads configuration and dependencies and performs analysis in memory, so you should allocate sufficient resources depending on the Jira instances. We recommend following Atlassian’s Jira sizing guide.
...