The procedure of staging any changes before they are made on the Production server is a recommended IT best practice. The following article describes how to set up such environments: Establishing Staging Server Environments for Jira This is the core use case for which Configuration Manager for Jira was designed - automated promotion of Jira project configuration from Test through Staging to Production Jira environment.
< 10 min
3 Jira Servers*
Project Merge Mode
*3 Servers are required. Test, Staging, Production. The Staging server should be an identical or close replica of the Production server.
This use case has two major phases: promotion from Test to Staging and promotion from Staging to Production.
Review the change and impact analysis in the Analyze step of the deployment Now that Staging is a close or identical replica of the Production, during this analysis, you will see how the deployed configuration will impact the Productionserver.
Proceed with the deploy (the change and impact analysis shows that everything is OK)
Test the deployed changes - the actual testing depends on the changes and may include the creation of issues, exercising issues workflow, etc. Declare SUCCESS/FAILURE - if the deployment and testing are successful proceed with promotion to Production.
In case of failure locate the error and make changes in the Test environment to address it.
In case of a failure. Restore at the Staging server the System snapshot created at step 3 above
Do not make changes directly to the Stagingserver - it needs to remain the same as Production.
Staging: Create snapshot of project A.
Production: (optional) Create a system snapshot for backup.
Production: (optional) Limit the user access to Jira. It is recommended that all changes to production servers are done during maintenance windows when user access is limited.
Review the change and impact analysis in the Analyze step of the deployment
Now that the changes were staged at the Staging, the change and impact analysis shown at this step should be identical with the one on Staging, those changes were tested and you can proceed with confidence.
If the change and impact analysis are different than the one on Staging then both environments are different and this should be corrected.
Proceed with the deployment (the change and impact analysis shows that everything is OK )
Declare SUCCESS/FAILURE based on the deployment result. If it is successful and the access to the users was limited, open the system for all users.
Only in case of a failure - restore at the Production server the System snapshot created at step 6 above. Restart the process from the beginning, if the staging server is identical to the production, failures at this point aren't possible.
Do not make changes directly to the Production server.
Automation of the above steps can be accomplished using the public REST API.