Source Control to manage Jira project settings changes

[t3knoid]

Is anyone else using source control to track changes of Jira project settings? For example workflows can be exported as an XML file. I export this and add this into our git repo. What other settings such as this can I put into source control?

[Nic Brough -Adaptavist- · Accepted solution]

A number of people I've worked with/for have dabbled with this, but all have ended up deciding it's not worth it.  It's quite a polarised thing - you can either

• do it properly and completely with a second Jira installation, an app that can export and import settings and a pile of code to trigger and source-control those.  This is going to take you years of coding (and if any of the partners thought it was worth it, they would have done it by now)
• choose to neglect some aspects so you don't have to code, at which point you lose all the possible benefits of source controlling changes

It is far easier and better to do manual change control.  Have a Jira project for change control on Jira and drill it into your admin team that "no Jira record = do not make the change"

[t3knoid]

This makes sense. Although I do still want to be able to track changes to things that have available settings in an XML file. I get that it's tedious and manual, but its even more frustrating when I lost a bunch of settings and have to figure out what has changed in the settings. For scripts, I've basically created a text file containing the script and settings that I manually modify to reflect the change I've made and check-in the file. The Jira project makes a lot of sense for change control. I'll most likely lean towards doing that also. Thanks for your input.

[Nick Pan]

In the past, I implemented "Jira configuration as code".  Here's a summary:

• define a text file format for Jira configuration (I used YAML)
• populate those text files and manage them in a source control system (e.g. Git) - they are now the "source of truth" 
• implement a pipeline which regularly reads Jira configuration (using API calls) and checks that it matches source.  If there is a mismatch, raise errors to the admins to inform them that someone made an unauthorized config change
• to properly make a change, first change the source text files and go through standard Git-based approval processes before applying those changes in the system

You now have a record of what was changed, when, and why.

Caveat: this isn't source in the sense that it generates the equivalent Jira configuration - the "syncing" must be done manually.  This is because Jira doesn't have sufficient write APIs for configuration (particularly around automation rules).