Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


DevOps best practice for Jira Administrators

One of the most significant challenges for Jira Administrators is the lack of DevOps practices and tools for configuration changes.

Some of the challenges are:

  • How do we merge configuration changes from the testing/sandbox environment and deploy them safely into production?
  • How do we know what is implemented in the production instance?
  • How do we track why a change was made, by whom, and when?
  • What happens if we need a quick rollback?

While for code-based changes, in the developing world, using source control tools such as Git with Bitbucket or GitHub is part of basic DevOps practices, configuration changes stayed behind with limited tools and best practices in this area.

The common methods to deploy changes for Jira administrators are:

Perform the change directly on the production instance.

In this case, the risk is clear - all the changes you are doing immediately impact the production instance and users.

If your instance is small, the change is minor, and the impact is limited, you may consider taking this risk. Otherwise, working directly on the production environment without testing the change impact before is not recommended. The advantage, in this case, is the short time it takes to deploy your change.

Make the change in a sandbox environment, test it, then manually make the same change in production.

This is the standard way to make changes and reduce risks.

You can make your configuration change on a sandbox without disturbing the production, test it properly and only then perform the same actions in production. The risk is lower because the change was tested, but you can never be sure the configuration is identical in both environments because you changed it manually. Obviously, it's not enjoyable for the administrator to make the change twice, sometimes with a delay.

In both cases, tracking the changes and the ability to do quick rollback is limited.


On Sunday this week, Atlassian Community Event was hosted by Salto in Tel-Aviv, celebrating the Jewish "Purim" holiday and the 26h community events in the last four years.

About 50 Attendees joined to hear about DevOps best practices for Jira administrators.

Salto presented slides and a demo of how to manage your Jira instances better, merge your changes between environments, track the changes on your production instance, and more.


 It was exciting to watch the demo and see how Salto provides a solution necessary for managing configuration changes on Jira instances.

You can have more info here:

If you join team 2023 in Las Vegas, I recommend looking for the Salto booth and asking for the live demo.


1 comment

Megan Schumann
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Apr 05, 2023

@gal Thank you for taking the time to share these suggested improvements that would help Jira Admins move less manually from trying out new things in the sandbox to productionizing them. It's useful to know that is a current sore spot for DevOps minded admins!


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events