Implementing Jira Admin Changes in a Live Project Environment

[Sundram Trivedi]

I have a question regarding the implementation of Jira admin changes in an active project. Since our current Jira site is already running with live projects, I am unsure about the best approach to make necessary admin changes without causing any disruptions or downtime.

Could anyone provide guidance on where and how to implement these changes in such a way that the ongoing projects and their workflows are not impacted? Specifically, I'm looking for advice on managing configurations, permissions, or other admin tasks that may require changes to the system while keeping everything running smoothly.

Your insights or recommendations on handling this would be greatly appreciated!

[Rune Rasmussen]

As with all things it depends on the specifics.
But apart from that, I would say:

If your change is big enough, or you are uncertain, test it in a Sandbox or a dummy project.

Consider if the change should be made outside regular business hours or if it can be made during the work day, and then communicate when you intend to implement the change.

Also communicate what the change is and how it impacts the current way of working.

If you're working with Company Managed Projects consider having a new scheme, screen, workflow, or whatever, ready. This makes it easier to make the change and to roll back in case something doesn't work as intended.

[Ulf Johansson]

Agree with @Rune Rasmussen 
Those advices are professional.

Another way is to deploy a small change and let the user run it for a day or two.
Then keep on deploying small changes until the release is done.
Important though is to have confirmed users for acceptance testing after every deploy.

[Support eisonesoft]

Dear @Sundram Trivedi 

First and foremost, it's very important to know the current configuration of your projects. Keeping Jira's current configuration documentation up-to-date is crucial.

With add-ons like Smart Configuration: Documentation for Jira you can get the 📋documentation of your Jira Project Configuration quickly⚡️up to date🗓️ and ready to be understood by non-admin👥users.

The second step is to thoroughly gather requirements and detail how the tool is expected to function.

With the Smart Configuration: Documentation for Jira add-on, you can generate a current version of the documentation for your current configuration.

Once the version of the documentation is generated, you can implement the changes in the test environment.

Once the tests in the test environment are satisfactory, we can use the Smart Configuration: Documentation for Jira plugin again to compare the previous version of the configuration with the current configuration and thus see each of the updates that have been made to the configuration, and then deploy it to the production environment.

For automatic deployment of configuration changes from the test environment to the production environment, you can use other addons such as Configuration Manager for Jira (CMJ).

[Kimberly Anderson]

You should use a sandbox

[Sundram Trivedi]

Hi, thanks for the response.

I have a sandbox, but without Confluence and GitHub integration. Because testing release notes automation is difficult and need Confluence for storing notes and GitHub to filter merged issues.

[Alfonso Leiva]

Hi Sundram,

There isn't a recipe to fit all the needs.

On a high level, in Jira there are only a couple of places where when doing a change, you will get an alert about possible impact. But in general, it is up to the Jira admins to understand how the projects are configured.

To explain this a bit better: if you remove a field from the Edit screen, you will not know if an automation rule is attempting to update it, and will only see it failing after you already did that, unless you specifically checked everything else in the project.

There are some options, though, to test some things: using sandboxes, or replicas of your site (free ones to then shut-down); or third party apps to move configurations from a sandbox or a test site to the production one. But still, there are risks.

The best you can do, on a high level, is be aware of the possible interdependencies among the different project configurations you can see on the Summary section of the Project Settings.

Trying to come up with that:

• Issue type scheme (ITS): you should not rename them, since that affects the whole site. But if the project is using their own ITS, you can add more, keeping in mind the Workflow Scheme is currently using. Removing one from a scheme will trigger a wizard so you can re-map the issue type to an existing one. Also there, you need to be aware of the Workflow Scheme impact.
• Workflows: there are some restrictions when editing workflows. If I'm not wrong, removing statuses is not possible, so you need to create a copy, assign it to the scheme, edit the original and then update the scheme back again. 
• Issue Type Screen Scheme: if you make changes to the screens, the impact could be at workflow transition validations, such as a required value on a transition. Or a required field on the Field Configuration Scheme
• Permission Scheme and Roles: these are the most important ones to keep an eye on. The best practice is to use Permission Schemes using Project Roles, and then set up Project Roles on each project, so you don't need to create several schemes. You need to pay attention, though, to each one of the permissions. There can be many approaches here, but I would recommend having at least 3 roles: Admin, User and Viewer. There can be two "User" roles as well, with different permissions, such as one being able to create issues and Edit them while another only vieweing, transitioning and commenting. A "Commenter" role can also be created. And for each role you must adjust the Permission Scheme accordingly.
• Automation rules: since you can do almost anything with automation rules, there is always a chance to break something by making changes to any of the previous one
  • A rule with a condition only for specific issue types, that you may have removed from the scheme.
  • Using a Transition Issue action, on a workflow you just removed an status from.
  • Attempting to update a field value, that you removed from the Edit screen.
  • Automatic transitions using the "current user" that now changed their role to another one that is missing that permission.

All of that being said, the answer is that there is no easy path.

I agree that for not so experienced Jira Admins, one way is to make small changes at a time, where possible, to make sure nothing heavily breaks, and it is easier to then roll back the changes, instead of attempting to identify where the error is among many configuration changes.

[Narasimha Murthy Jalla]

Hello Sundram,

Here are the few strategies you can follow to ensure smooth changes:

Set up replica of your live instance to test the changes first. This allows you to evaluate the impact of the changes without disrupting the live projects. Once validated you can deploy the changes to prod, either manually or using addons like CMJ

Implement changes incrementally, starting with small user group or project. This helps ensure that any issues are caught early.

Schedule admin changes during low traffic periods to minimize disruption. Communicate with teams in advance about the changes.

Use reusable schemes (workflow, permission, notification schemes) across projects. Changes to schemes can be applied to multiple projects at once, reducing the need for direct edits.

[Suzi Firth]

Hi,

I always use Sandbox to develop and test changes before implementing them.

I recommend taking the time to understand what would be the affect if someone tried to use that particular function whilst I was making the change.

This happened to me recently. I was changing a html format email in an automation and the automation ran whilst I was making the change. It resulted in the manager not receiving the email approval which is not great. So changes like this where its visible to the reporter or participant, I now run outside of hours.