nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Jira service desk release management

Joakim Heijbel

What is the best way to manage continuous development of an existing "live" service desk project. We are live since a few months back with quite many active users. Now when we have new development needs we are not finding a good way of managing it without risking disruption to the daily work?!?

Have searched but do not find any relevant info.

//Joakim

Accepted answers

Meg Holbrook

Hey Joakim, welcome to the community!

I have a test instance where I do most all of my development. There is additional cost for having two instances, but I find that having some sort of staging environment is the difference between a major service issue that affects your whole org VS a small and easily-fixed oops in my development instance.

Back before I started using my test instance the best way to manage for me was developing late at night when I knew no one would be impacted, then running tests, and scurrying out at the crack of dawn. Highly do not recommend!

All comments

Meg Holbrook

Hey Joakim, welcome to the community!

Joakim Heijbel

Thanks Meg,

Few follow on questions:

-What are the key reasons for not adding another project into the same instance and do the testing/trying out there?

- Do you know if there is any way to copy an existing project with all it's settings for the test instance so you do not have to do all the configuration once again?

...seems Atlassian have some work to do here to stabilize Service Desk release management ;-)

Meg Holbrook

The reason that I have a separate environment is so I can also test new add ons. The method of replicating your current installation is going to be largely dependent on whether your team utilizes Cloud or Server. Cloud can be really tricky, and I'd advise just manually moving over your configurations. It's slow, but is also a one-time setup pretty much.

Server walkthrough here.

Resources for cloud installations here:

https://confluence.atlassian.com/confeval/other-atlassian-evaluator-resources/atlassian-cloud-staging-and-testing-environment

https://confluence.atlassian.com/jirakb/how-to-migrate-projects-from-one-jira-cloud-application-to-another-779160766.html

Meg Holbrook

Another reason for a different instance is that if I OOPS anything, it doesn't touch my production instance in any way. I've made a workflow change in the wrong workflow before, I've crashed the email server with a bulk update, things happen.