There’s a reason Jira is the leader in its space—it’s flexible, extensible, hardy, and nicely integrated with the whole Atlassian suite and standard DevOps toolchain. But if you’re the administrator behind it, Jira can be a lot of work.

Jira lacks what we might call “native admin tools” to help you see everything that’s happening and configure things quickly. And when you have thousands of users all asking for customizations, pressure from the business to move quickly, and must do lots of the configuring by hand, things get messy. You leave behind bugs, disorganized screens, duplicate issue types, and compounding clutter.

It probably means you can’t move at the speed the business needs you to. 

That’s why we’ve launched Salto for Jira—to let you apply all the power of DevOps to finding, understanding, copying, checking, changing, and deploying configuration updates, in the cloud or data center. It lets a Jira team of two act like ten.

‍

Common challenges to keeping Jira users happy

The great thing about Jira is it has grown from mere bug tracking into a sort of “citizen developer” platform where any user can build boards and create filters. It’s highly configurable, and people tend to customize it to the max. But all that flexibility means users leave behind successive layers of sedimentary changes that affect future configurations.

And while everyone is changing things, you don’t have a proper set of tools to make quick, accurate configuration changes on the backend. If you use a sandbox strategy, you have to build that customization in the sandbox, only to rebuild it in testing (UAT) and then again in production, because there’s no way to move or “deploy.”  

Furthermore, admins tell us they struggle to answer basic questions about what’s actually implemented, or to predict what’ll break if they change a custom field. 

Here’s everything we hear from Jira admins that inspired us to extend Salto support:

1. No way to customize without impacting production

As we alluded before, Jira doesn’t offer any way to copy things between your testing and production environments. And while some Jira add-ons allow you to copy some customizations over, they lack essential features, like the ability to copy cloud-to-cloud or copy automations. 

As you well know, it takes a lot of time to reconfigure things in each environment, and doing so invites errors. Plus, if you want your testing to be reliable, you have to configure your staging instance to be an exact replica of production, which presents its own set of challenges.

2. Administrators can’t figure out what’s implemented or see what might break

Complex Jira instances contain hundreds or even thousands of custom fields, workflows, screens, automations and other configurations that bump and clash in non-linear ways. Jira doesn’t have a feature to see and inspect all of this. 

If you want to figure out all the places a custom field is referenced, you have to do so by hand. 

3. No way to track changes or leave a proper audit trail

Most administrators inherit a Jira instance and it can sometimes be years before they realize that it wasn’t built all that logically. And because Jira’s audit log only tracks some configuration changes, you never have enough information to know why it was set up that way. 

And if you see a new change that breaks one of your workflows, who do you ask about it?

Salto lets you use DevOps to better manage Jira configurations

Salto for Jira Cloud and Jira Data Center gives you tools that let you apply DevOps practices to managing Jira configurations and customizations. It turns all your Jira instance configurations into readable text, and lets you sync them with Git, which then gives you all the power of managing “code.” You can find, understand, copy, check, change, and deploy configuration updates.

This allows you to deliver complex customization changes faster, more accurately, and with fewer bugs and less downtime. For example:

1. Customize Jira without impacting production

When you can view your Jira instance in Salto, you can manipulate it in new and exciting ways: 

• Compare instances and understand the differences
• Push changes between any two instances
• Selectively deploy just some changes, but not all
• Identify dependencies you may need to add to your deployment 
• Align sandboxes to production, and vice versa
• Bulk update configuration elements

‍

This means that finally, if you build something in a sandbox, you can “copy” it into user testing (UAT) and then into production without rebuilding anything by hand. Salto will run some automatic tests each time to alert you if your change will cause issues, or if there are unforeseen dependencies. (And you can select only the things you want to deploy—so, if you want to just deploy a few new custom fields but not a new dashboard, you can.)

This works for every configuration element in Jira. So unlike other applications that don't support cloud-to-cloud copying and don't let you move basic configurations such as automations, Salto includes automations, dashboards, saved filters, and more and also allows you to be selective about the changes you copy.

Once your new customizations are live, you can sync your sandbox to production, so they match. 

Advanced users can even implement full continuous integration and continuous deployment (CI/CD), with automated testing and alerts.

‍

‍

2. Know what’s implemented and see what might break

When you have a full snapshot of your Jira instance in Salto, answering the question, “What will break if I change this custom field?” is easy. You can:

• See a full “blueprint” of all your Jira instances
• Search your entire configuration 
• Locate and analyze the dependencies of any Jira configuration element
• Set alerts for when someone changes your configurations

‍

Now, you can search Salto and see everywhere a custom field appears. If you want to update it, you can run a “find and replace” function and preview it to see what’ll change before you push it live. 

To set up alerts to be notified of important configuration changes, select that configuration in Salto and whether you’d like those alerts in email or Slack.

‍

3. Track changes and leave a full audit trail

Salto syncs with Git, so you’ll now have full version control over all your Jira instances:

• Document everything and leave an audit trail
• Save versions of your configuration
• Trace configuration changes back to the person who made them
• Roll back changes if necessary

‍

To leave bidirectional documentation, simply add the relevant Jira ticket number and the Git commit and the Salto integration will automatically link the ticket. You can then read Jira ticket notes and then trace it back to the change made in Git, or trace a change you see in a Git commit back to its Jira ticket.

If anything goes wrong, rolling back those changes is as easy as reverting to a prior version.

‍

‍

And if those individual use cases don’t get you excited, maybe this will—with Salto translating your Jira instance into a textual language, you can collaborate on everything. You can fork changes, review with peers, and check each other’s work in a way that just isn’t possible otherwise. It’ll decrease bugs, speed up release cycles, and help you respond as fast as the business needs you to.