As Jira administrators, we’re all in different stages of the Jira learning and implementation journey. For those of us just getting started, we’re simply trying to learn as much as possible about how the application works and how our users leverage it. If you’re in this phase right now, you’re likely just trying to survive the never-ending barrage of Jira configuration requests.

Thankfully, this phase won’t last forever! After some time and with experience, you’ll evolve from a reactive mindset (Fix the broken thing now!) to a proactive one (Prevent the breakage before it occurs!). Our focus shifts to finding ways to make the configuration simpler and easier to maintain.

How so, you ask? You might create a sandbox environment so you can test major changes before unleashing them on production. You’ll leverage change management practices to collect, fulfill, and document configuration requests. (And hopefully, you’ll use Jira for the tracking!)

Finally, for those who’ve been administrators for a while, you might have robust processes and less chaos and be looking for ways to make Jira management more, well… manageable. You’ll start introducing ways to automate everyday admin tasks so you can respond faster and focus on more impactful work. Users familiar with development or operations processes call the practice of software version control, collaboration, and automation DevOps. I simply call it smart application management.

Jira Learning and Implementation Evolution

Let’s start by finding out where you are on your Jira journey.

‍

‍

Now that you know where you are, let’s move you forward on the timeline by implementing a test environment and automatically deploying your changes between environments.

Creating Your Test Environment

Regardless of where you are on your Jira journey, it’s never too early to create a test or sandbox environment. A separate environment is the safest way to experiment and explore features without impacting actual production data.

In Cloud

If you have Jira Cloud Premium or Enterprise, sandbox functionality is already built into it. You can create sandboxes, delete them, and copy production data at any time.

Visit admin.atlassian.com and click the “Products” link in the top navigation bar. Then, click the sandbox link on the left sidebar.

‍

A sandbox operates as a replica of your production environment. It is connected to production, has a similar URL, the same user limits, and has similar data. You can create a sandbox for each product. (E.g., Jira, Jira Service Management, Jira Product Discovery, and Confluence) After creation, click the “Copy production data” button to choose whether to copy all or some Jira project data. You can also either include or exclude attachments.

In Data Center

For Data Center users, you can replicate your application using a different physical server or a virtualized solution. Instructions are available in Atlassian’s documentation. Just make sure that your configuration matches production settings as much as possible. Here’s a partial list of settings to match:

• Application configuration
• Same or similar data
• SSL
• Load balancing
• Reverse proxy settings
• OAuth authentication
• Logging and profilings

Many application administrators don’t have much server management experience, and that’s OK. (I don’t!) Talk to your system administration, infrastructure, network, security, and compliance teams to uncover any additional technical considerations.

After installation, Data Center users can apply a developer license (recommended) or a free trial license to their sandbox environment. Login to my.atlassian.com, click on the related product, and look for a link labeled “View Developer License”. Copy the license key, log in to Jira as an application administrator, and apply the license on the “Versions & licenses” page in the “Applications” admin area.

‍

‍

Using Your Test Environment

Now that your test environment exists, what should you use it for? I use mine to test significant changes, large imports, app installations, and removals, as well as proof of concepts, clean-up activities, and more. And, of course, in Data Center, I use it to test migrations and upgrades. Essentially, I use my test environment for any change that would annoy users or interrupt their work if it went wrong.

‍

‍

Deploying Changes from Test to Production

You’ve created your test environment, it has the latest version of the configuration, and you’ve even made and tested an impactful change. You’re ready to make the change in production, but how should you do that? You can do it manually or with a helper app like Salto Configuration Manager for Jira.

Deploying Changes Manually

Let’s say you’ve been tasked with removing some unneeded Jira custom fields. You’ve researched all the potential impacts on filters, boards, workflows, automation rules, apps, scripts, and more. You’ve removed the fields in the test environment, tested the configuration, and fixed all the broken objects. Did you take good notes? Did you document the names and IDs of all the elements you changed? Did you record how long the effort took from start to finish? You’ll need that information to essentially re-do the same actions in production. Also, since production is constantly changing, there could be some recently added, edited, or removed elements or new dependencies to address. Manual deployment is time-consuming, prone to human error, and there’s no good way to roll back if you run into unexpected complexities. Luckily, Salto can compare differences, manage dependencies, validate changes, and manage the deployment process for you. Salto can also handle errors and roll back your Jira configuration to a previous state.

Deploying Changes with Salto

It’s quick and easy to get started with Salto. Simply sign up and connect Salto to your Jira Cloud or Data Center applications (both production and sandbox) by entering a few connection details.

‍

‍

Then, have Salto fetch your application’s configuration data.

‍

‍

Within minutes, you can see all the objects in your Jira Software, Jira Service Management, or Confluence application.

Here are the steps to push a sandbox change to production. First, click the “Compare and Deploy” option in the top navigation. Then, create a new comparison between two applications. In my use case, the sandbox environment is the source, and the production environment is the target.

‍

‍

Next, Salto shows all the differences between the two applications. Over a thousand were detected. Can you imagine managing all these differences manually? No thanks!

With Salto, you can be completely selective about what gets deployed to production. You can deploy a single change, an entire Jira project, or multiple changes and Jira projects together. This way, you can pick and choose the elements that are ready for production without impacting other changes that are in progress in the sandbox environment.

‍

‍

Next, let’s find one of the fields removed in the sandbox and have Salto make that same change in production. You can deploy one or many changes (including entire project configurations) at the same time. In this use case, I’m only ready to deploy changes related to removed fields. I’ll promote the other differences detected in a future, separate deployment.

I clicked the “Deletions” tab and searched for a custom Jira field I don’t need anymore called “Date received.” Salto reveals where this field is used and any dependencies in the production application. Next, click the “Preview deployment” button at the top right.

‍

Salto will validate the data and check for any potential deployment problems or errors to address. Finally, click the “Deploy” button at the top right to execute the deployment.

‍

‍

After the deployment, Salto will display a summary of the changes made. If there were any errors, they are shown here so you can fix and redeploy them. If needed, you can also roll back the changes to a previous stable version.

‍

‍

As a final (optional) step, I’ll export the deployment summary in CSV format or take a screenshot to attach to a configuration change record tracked in Jira. I’ll also do some testing to ensure the change was executed in production as expected. After seeing how easy and robust the compare and deploy process is with Salto, I doubt you’ll ever want to go back to applying manual changes again.

‍

Activities to Try

Now it’s your turn! Sign up for a Salto account and test deploying a small change to see how it works.

Ideas

• Remove an unneeded scheme or setting from the sandbox environment
• Create a new Jira project and push its entire configuration to production
• Use the sandbox to build a proof of concept for onboarding a new team to Jira

Resources

• What are sandboxes? (Jira Cloud) — https://support.atlassian.com/organization-administration/docs/what-are-sandboxes 
• Creating a test environment for Jira (Jira Data Center) — https://confluence.atlassian.com/adminjiraserver/creating-a-test-environment-for-jira-966063324.html 
• What are developer licenses? How are they used? — https://www.atlassian.com/licensing/data-center 
• Get a Jira Data Center trial license — https://confluence.atlassian.com/adminjiraserver/get-a-jira-data-center-trial-license-1189482127.html 
• Deploying with Salto — https://help.salto.io/en/articles/9636754-deploying-with-salto 
• How to Move an Entire Jira Project from Sandbox to Production — https://www.salto.io/blog-posts/jira-entire-project-migration-salto