Configuration control of Atlassian configuration

[David Holshouser]

I'd like to check in the configuration of my Atlassian server but I can't find documentation to guide me.

Searching for "configuration control of server configuration" or "revision management of server configuration" on this site is fruitless due to the numerous uses of those terms.

So I'll ask here for help.

I'd like to commit the configuration of my server, not the projects and certainly not any project data, but issue types, screens, custom fields, workflows, all of the schemes and configurations, statuses, resolutions, etc. All of the parts that make up the configuration of the server. If necessary, committing all of the project configurations would be fine and probably a really good idea as well.

I've been able to do this on previous CM tools (eg: trac/svn/git), but can't figure out how to do it on the Atlassian toolchain.

This would also facilitate propagating the configuration to another server as needed for any number of reasons. For example: My company has several air-gapped networks where sneaker net is the only way to move data between networks. If I could capture the configuration on my Atlassian server, then I could perform a security scan on the configuration and copy it into a secure network to rehost (with appropriate licensing) the identical capability on another server.

If there are instructions for how to configuration control the configuration of an Atlassian server, please just point me there, but for now I'm stuck.

Thanks!

[Nic Brough -Adaptavist-]

Atlassian tools have so much configuration, this simply isn't possible.  You'd have to code for many types of scheme, of flags, of settings and the rest.

The closest you can get is on Jira, where the config is the most complex - there are tools such as Botron's Configurator, and Project Configurator which can export files by project or system ready to be used on the other end to replicate config.  You could source control those files, but they wouldn't tell you much about change if you compared versions of them.

[David Holshouser]

I don't plan on marking this answer as accepted.

It is certainly possible to develop an exporter tool for each of the sections in the admin section that is generic to the explicit configuration. Just because the tool has a highly complex capability of configuration doesn't mean the exporter must be infinitely complex. That's the very definition of xml. A self describing language. That really isn't an answer and certainly not one I'll accept.

Many other tools have accomplished this feat. These tools should as well.

[Nic Brough -Adaptavist-]

Ok, I understand your view.

But in the real world, the effort involved in writing a large amount of export code to create something a tiny fraction of admins might use isn't going to happen.