Moving the configuration changes between Test, Staging, and Production Servers

Configuration Manager for Jira (CMJ) by Appfire is designed to solve a wealth of challenges Jira administrators face. One of the most common uses of the app is for performing Change Management tasks within Jira, such as safely making updates to workflows, screens, and other project settings.

In the above video, you’ll learn how to use Configuration Manager for Jira to move changes through test and staging environments before deploying them in production.

For step-by-step instructions, visit this documentation page.

---

For your convenience, below is the transcript of the above video.

Configuration Manager for Jira, or CMJ, is a popular marketplace app, useful for solving many Jira administrator challenges. One of the most common uses of the app is for change management within Jira, such as safely making updates to workflows, screens, or other project settings.

We refer to this as the “test-staging-production” use case, because we employ an IT best practice of moving the configuration change through test and staging environments prior to deploying it in production, and CMJ makes this process super easy.

What are TEST, STAGING, and PRODUCTION servers

You’re probably familiar with what a production server is — this is the Jira server where people get their work done and where you want to minimize downtime and broken configurations. But you might be wondering what the TEST and STAGING servers are used for:

The TEST server (also called a Development instance) is a no-risks playground. Here, administrators and delegated users can test changes and new configurations.
The STAGING server is a pre-production environment that should be set up as a clone of the production server. Here, you can perform user acceptance testing and understand how your proposed changes would behave in production without putting the production system at risk.

For this demonstration, let’s say the Legal team has identified a need to add a second reviewer to any legal docs created or updated before closing out the task, and they’d also like to add an attachments field to the issue screens so they can attach meeting notes related to the ticket. So they open a change request to ask you as the administrator to update their existing Legal project workflow and screens.

At a high level, this use case follows this process:

One, configuring and testing the desired change in a TEST environment
Two, moving the tested configurations to a STAGING environment for user acceptance testing by the stakeholders impacted by the change.
And three, moving the approved configuration changes to the PRODUCTION system.

Set up

First, install Configuration Manager on each server if it’s not there already. You’ll only need one paid license for the PRODUCTION instance and you can use two free developer licenses for the TEST and STAGING servers. Once you purchase CMJ for production, you can get free developer licenses by clicking the View Developer License link from the license page on my.atlassian.com.

Then, you’ll need to transfer configurations from the Production server to the other two servers, and you can use Configuration Manager to do so. For the TEST server, deploy your Production system configurations.

You don’t need to move all of the data here – just the configurations. For the STAGING server, create a clone of your production server with both configurations AND data and deploy those to the STAGING environment. More information about how to do this can be found in the Jira Clones use case in our documentation.

Part 1: Configuring the proposed change in Test server

Once the Test and Staging servers are set up, your first step is to implement the workflow and screen changes on the Test server. In this case, we’ll add a new status and transitions to the existing workflow for Legal projects. We’ll also update the create issue screen per their request to add the attachments field.

Go through a few motions with the new workflow and screen to make sure they’re behaving correctly.

Once everything looks like it’s set up and working correctly in the Test server, it’s time to move the new configurations to the Staging server for User Acceptance Testing. Use Configuration Manager to create a project snapshot for the main Legal project with the updated workflow and screen scheme from the Test system.

A Snapshot represents the state of Jira configuration objects at a given point in time. They capture the state of the objects as well as their relationships to each other, so we use them to easily package and deploy configurations between servers.

With a project snapshot, you can specify if you want to include filters, agile boards, and dashboards, but since our changes for the legal team don't impact those configurations, we can leave them out.

Part 2: User acceptance testing in Staging

Next, download the snapshot from the Test server and deploy it to your staging environment using the Project Merge mode. This mode ensures that changes will be made to existing projects rather than creating an entirely new project upon deployment.

Prior to completing the Deploy action, Configuration Manager will go through an analysis process and present a summary and detailed information about the changes to be applied. Review this report tо understand how your proposed change impacts existing projects – since the Staging server is a close replica of production, take careful note of the impacts here. Once everything looks okay in the analysis, proceed with the deployment in staging.

You can also review the Audit Log to give you greater visibility into each project or configuration that was impacted by the change.

Then, notify the right stakeholders to perform User Acceptance Testing on this server (likely some individuals from the legal team in this scenario). They will make sure the desired workflow and screen change was implemented correctly and no undesired changes or consequences were introduced as a result. The actual testing completed here will depend on the changes you made and may include the creation of issues, moving issues through new statuses to confirm they transition appropriately, checking for updated screens, and more.

If there are any problems with how the system is functioning with the new workflow or screen, go back to the Test environment and fix the errors. Reset your staging environment back to the Clone of your Production server, and deploy a new project snapshot from the test environment.

Part 3: Deploying the configuration change in Production

Once everything is working as desired in staging, it’s time to make the change in the production environment. The process from here is pretty similar as what we just did to deploy the project from TEST to STAGING, except now we create the snapshot in the Staging environment and deploy it to PRODUCTION.

Note that before you deploy to production, it’s recommended to create a system-level snapshot for backup in case anything goes wrong. Also note that as a best practice, you should perform these changes during maintenance windows or weekends when users are less likely to be online.

At this point, you shouldn’t have any errors when deploying to production because you fixed all of those in staging. If you do, it’s an indication that your production and staging servers weren’t exact clones of one another. If that happens, don’t fret, you can rollback to the previous state with the system snapshot you created prior to making the change.

Note: While the deployment is running, if anything unexpectedly goes wrong while applying the change, CMJ will automatically roll back to the previous state of the instance.

And that’s it – you have your updated workflow and screen for the Legal team. I hope you enjoyed learning about how to use Configuration Manager for Jira to safely make configuration changes in Jira.

Try Configuration Manage for Jira for free

How to perform change management tasks in Jira using CMJ

Subscribe for updates