Jira Software Server 8.5.1
Jira Service Desk Server 4.5.1
What is the best way to handle change/configuration management for a Jira server (both service desk/service management and software)? Is there any way to get around tedious and error-prone screen by screen comparisons with mouse clicking?
Our goal is to setup a blue/green deployment environment and then have a development server behind that. I know we can use the full site XML backup/restore feature (in combination with the data directory backups for attachments, etc.). That is great for taking the latest production instance and replicating it downstream to refresh the development and test servers. However, since it wipes out existing issues, we cannot use it to apply changes upstream (from test to production). This means we'd have to apply all of those changes manually. Atlassian support has indicated they have no native way to handle changes in an organized way.
There must be some way to solve this problem. If it was possible to create a backup of just the issues without the configuration changes, then it would follow we could backup production issues, then apply the full XML backup from test to production, and then apply the issue backup to production to restore the issues. But I haven't found any way to backup just issues.
Any ideas or experience doing this?
So here I would say time to use docker.
Correctly, wrap your configs into docker compose files OR set your configs into git (server.xml, setenv.sh).
Also, I would recommend you look into that one
I would recommend you start from proper documentation of upgrades, automate your steps via ansible or other tool, include that thing into cvs.
And then add into CI.
Just wanted to report some of my findings on this topic. I'm not totally satisfied with the setup quite yet, but it is working pretty well so far.
The infrastructure is setup like this using docker-compose: JSM container, postgres container, and a reverse proxy container to handle the SSL.
We grabbed the Botron Configuration Manager for Jira plugin (although to be honest this should really come stock; it's just too important). This lets us take snapshots and execute deployments seamlessly. However, the CM tool only covers the project and issue configuration, not system configuration (e.g. user directories, global permissions, roles, etc.).
So then we tried taking full XML backups using the built in backup/restore functionality. However, this caused problems. One was with the tomcat reverse proxy configuration; it wouldn't allow changing the proxy host name after the restore was applied. So for now there are still a lot of manual steps to setup each instance with the correct base settings (as well as install the plugins) before we can apply the snapshots with the CM tool.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.