You know that anecdote, “If I had had more time, I would have written you a shorter letter”? It’s the same when managing Jira. If you had more time, you’d build things right the first time, and build them to last. But for most Jira admins, that’s not their reality. 

For most, you’re so pressed for time you let a workflow grow 20 steps long, with hundreds of transitions, and never mind the fact it won't even display on-screen and you can only view it in XML. The fires burning in other apps are more pressing.

However, there are ways you could be building smarter with the limited time you have, and DevOps can help. DevOps is a practice that combines methodologies, concepts, and tools to help you release higher-quality changes faster. It’ll help you eliminate steps, save your work, and repeat patterns. If you practice DevOps when managing Jira, whatever time you can commit gets united into one clean and resilient approach to keeping Jira running and users happy.

In this guide, we explore what using DevOps for Jira configuration changes can mean for a Jira administrator, and how a tool like Salto, which offers much-needed Jira admin tools, can help. Plus, here’s a question to ponder as you read: What if there are no legitimate complaints about Jira—only instances that were set up wrong?

‍

‍

Left unattended, Jira grows tangled—but it’s fixable

The challenge with Jira is accomplishing as much as you can within the limited time you are given. For most administrators, that means racking up technical debt in return for speed—they make decisions they’ll regret later to get Jira back up and running now. 

Rather than reviewing all existing Issue types, they simply create a new one, and then another, and then another, promising themselves they’ll be back to consolidate. 

But do they? Are they ever less busy? 

“Jira comes with 6-15 default issue types,” says Rachel Wright, an Atlassian consultant with seven years of experience managing Jira. “Yet the first company I worked for had 300. For no good reason. People just kept creating them because they didn’t realize how they worked. But of course, you’re supposed to share configurations and common settings, and someone needs to govern that.”

Even templates don’t necessarily prevent companies from building haphazardly. Many teams have manifold use cases and too many admins (who can add new admins) which cause the configuration to grow, compartmentalize, and sprawl. Without a steward there to say, “Let’s pause—what impact will this change have five years from now?” the complexity compounds.

That’s how you get into a situation where you face these common Jira issues:

1. You can’t move all changes between instances, nor selectively deploy

Already using sandboxes? You’re ahead of the curve. But you also know that Jira doesn’t support moving complete configurations between instances. Several apps on the app store can help, but only for Jira Data Center, and they still leave out important pieces like automations. So if you deploy, it leaves those out.

Complicating things, you can’t select what you want to move. As one user told us, “Configuration Manager will pick a whole bunch of unrelated stuff and pile that in with the thing you actually needed to deploy, which was maybe just one custom field. And you can’t stop it.”

If you have to move fast, how do you safely deploy just the changes you want, and not have to rebuild automations by hand?

2. There are far too many elements to manage

Most admins inherit an instance already rife with error. Probably, the prior administrator didn’t have a process for triaging requests. They accepted too many suggestions and rarely stopped to rationalize, delete, and reduce. They gave practically every user a custom field, and the snarl of dependencies means each successive update takes longer.

And if that complexity only compounds, when will you ever pay that technical debt down?

‍

3. You have no way to know what will be affected by a proposed change

Many admins live in fear of pushing changes live. For example, renaming a custom field. The renaming itself is easy. But Jira doesn’t automatically update all references to that field, so if your users rely on reports that use those filters, those reports break. There’s no way around this except to know where it’s referenced, by going through all the dashboards and filters by hand or with manual scripts.

How are you supposed to quickly make changes if you aren’t sure what will happen? 

‍

4. You can’t figure out what’s currently configured

Remember that theoretical 20-step workflow with hundreds of transitions? That’s not made up. A company we know really ran into that, and it really was too big for Jira to display. And even when you can view all projects, sometimes you still don’t catch hidden projects. There’s no Jira “blueprint” to show you everything.

If you don’t know what’s configured, how can you know if it was configured well? Or how to build upon it?

‍

‍

5. You can back up your configuration, but not revert specific changes

In the cloud, you can back up your configuration every 24 hours, but it’s the entire configuration—one big file. If something went wrong within that 24 hours and you wanted to revert just that one change, you can’t. It’s all or nothing. 

6. It’s difficult to control who makes changes

This one’s actually fixable right now, but often unaddressed: Some people who are administrators don’t understand that responsibility and, to get things done faster, create other administrators. This becomes a problem because there are no detailed system notes, and people can change each other’s changes. Sometimes, you return the next day to find something switched back.

If you don’t know who else is making changes, how do you ensure yours stick? Or know if they’re ever undone? 

‍

7. You have no way to audit past changes

Related to the above point, how do you know who has made which changes? And why? It’s important for internal teams to coordinate and build logically, but also critical for companies in regulated industries. If Jira is tied to critical processes and you have no visibility, that’s a glaring governance gap. 

If someone asks you why a change was made, what do you say?

‍

8. Jira can’t compensate for organizational issues

The smartest Jira administrator can still incur loads of technical debt if they don’t know precisely how the rest of the company works. For example, what is the full breadth of all issues every team runs into? Does one team need to display fields from Zendesk, but others do not? What’s the success team’s process for assigning, resolving, and reopening tickets? 

Any successful Jira configuration should mirror how the company already does things. But busy Jira administrators tend to try to wrap the company process around Jira’s defaults, to users’ great ire.

“A configuration can be great technical-wise, but terrible strategic-wise, and not help the company,” says Rachel Wright. “You both need someone to have the capacity to think long term for the future and really know the company’s existing prioritization and triage processes to tie it all together. If you want to build reports, first figure out the reporting requirements.”

With your limited time, how do you do enough research and discovery?

‍

‍

9. Users complain about the interface and Jira being slow

As with any system, adding more fields and elements creates more security schemes and slows down the system. A company that’s encountered the above eight problems probably encounters this ninth one because, unchecked, additions compound to degrade performance. 

With all you have to do, when will you find time to spring-clean Jira? And how would you know where to start?

‍

The good news: None of this is a Jira issue—it’s a config issue

Here at Salto, we believe there’s no unsolvable Jira problem for a committed systems thinker. It’s rare to hear a legitimate complaint that cannot be fixed. Someone thinks Jira can’t tell them their team capacity? It can—it just needs to be set up properly. Plus, all the apps on the marketplace really expand your scope.

But the key to doing it scalably is applying the principles of DevOps. 

‍

Applying DevOps principles to Jira (the process plus the tools)

The first step to applying DevOps should be no surprise—use Jira to manage Jira. Create an internal project to manage all your software and manage those bug and feature requests there. It’ll give you greater empathy for your users, and it compensates for the fact that Jira really doesn’t have a change management or “developer mode” suite.

From there, you’ll need a few tools to enact these processes: 

1. Extract the code with a configuration management tool (like Salto) and inspect what exists

The default way to do this is with XML, and if you’re comfortable with that, begin there, but know that XML won’t show you your configuration data. Whereas a tool like Salto can extract your Jira configuration—all of it, not just some pieces—into readable text, which you can then store in a versioning system like Git. 

By pulling your configuration out of Jira’s interface and into Git, you’ll finally be able to see everything in one place. (And if you’re using Salto, it’ll be simple, easy-to-read text—like below.) With this view, you get a full “blueprint” of everything.

‍

‍

‍

2. Deploy precisely what you want, and not things you don’t

Rather than deploy everything in your user testing sandbox, you can use Git and Salto to select specific configurations, and push just those live. Or, to identify dependencies that you should address before pushing your change live. 

It’s more granular than any other option—you can understand the differences between environments, quickly identify the changes you want to deploy, and deploy dependencies so your deployment doesn’t fail. 

‍

3. Use Git and Salto to conduct impact analysis

Jira can’t tell you where a filter is referenced, but you can figure that out in Git and Salto. Salto’s interface lets you run searches to: 

• Locate all mentions of a custom field
• “Find and replace” that field name with something else
• Check to see if that’ll cause any errors
• “Deploy” that change in Jira

‍

‍

‍

‍

4. Compare and sync your multiple instances

To avoid making changes directly in production, many Jira cloud and data center admins use additional Jira instances, such as Sandboxes or dedicated user acceptance testing (UAT) and other testing instances. But if you can’t copy all configuration changes, and must rebuild your automation rules and Insight Objects by hand, it introduces errors. 

But with Git and Salto, you can “copy-paste” configurations (or pieces of configurations) from environment to environment, then push the changes live. 

And with Salto, this can include many things that cannot normally be copied into or out of a sandbox. For example, automation rules. 

You can also sync your various sandboxes, to align them with production before you begin making configuration changes. Or, save configuration changes you weren’t done with, and not lose work.

‍

5. Manage changes over time, and leave a complete audit trail

Audit logs never give enough detail, do they? But if you are now capturing everything in a versioning tool like Git, you’re saving an image or “snapshot” of your configuration at every stage of change. Git acts like a time machine. You can see every change everyone has ever made. 

You can take that further and leave a full audit trail that incorporates the rationale for specific changes, too. In Salto, every change gets a unique ID which you can reference in the corresponding Jira ticket, and then mention that Jira ticket in the notes for that change. This way, anyone can trace the rationale back to the change, or vice versa.

“I always want to see what the configuration was last year to learn from whether those changes were good or not,” says Rachel Wright. “You can export workflows in a proprietary format, or XML, but you don’t get the configuration data. Only Salto and Git let you do that.”

‍

6. Set alerts for important changes

Salto allows you to flag sensitive configurations so if someone makes a change, you get notified. You can get notified if someone alters a workflow, or if an admin begins adding other admins. And while that may in and of itself not stop the problem, it lets you know who to talk to. 

‍

‍

7. Automate deployments

Once you’re managing Jira with DevOps, it opens the possibility to do more—like automating deployments. Rather than moving changes through a series of dev and test environments by hand, you can use a continuous integration and deployment (CI/CD) tool to automate pieces of it, like testing, alerts, approvals, and workflows. 

‍

‍

With DevOps, Jira becomes an open book—and a much shorter one

“If I had had more time, I would have written a shorter letter” writers often say. DevOps lets you do that with Jira. It gives you back time and stitches together all those little fractional hours you commit—the one hour there, the three hours there—with audit logs, documentation, notes, and precedent. The result is you can vastly improve the quality of your configuration changes, and make them much faster.

So, rather than wondering if something might break, you can check before you do. And rather than rebuilding automations by hand, you can make the changes in Git and “deploy” them just as you would anything else about your configuration in the sandbox. 

Applying DevOps to Jira puts you in a position to never have to accept a workflow that’s 20 steps long and with hundreds of transitions just because your users are demanding it. And if it saves you this much time and headache in Jira, just imagine—where else might DevOps apply?