How to manage your Jira technical Debt - Part 1

[#1]

Disclaimer:

• Applies to Data Center and Server deployments (don’t worry Cloud, I got you coming).

• You’ll need Jira Admin permissions, including global bulk update permission.

• I work at Appfire, so I’ll be using Appfire apps to show how you can do the recommended things.

---

What is Jira technical debt?

You ever walked into a Jira instance to find 15 variations of the same custom field? (Ow, amirite?)

i.e.

end date
end_date
end date.
end_date_
enddate
end date1

How about strolling into the workflow room and seeing 200 inactive default project workflow schemes laying around?

We’re not even going to open the basement door, because there are rumors of wild issue types for every possible business scenario roaming around like zombies.

You get the point.

All these duplicate, broken, extra, and unused configuration components are potential technical debt that should be addressed in your Jira instance/s.

Why address Jira technical debt?

Whether you are in the process of migrating from a server instance to a cloud instance**, consolidating server instances to a data center instance, or simply maintaining your existing data center instance, it is always good to run a tight, clean Jira ship.

When migrating from Server to Cloud, garbage in = garbage out. Meaning that if you don’t address your tech debt on the Server instance before migrating to Cloud, you have to deal with that tech debt on the Cloud instance. A better process would be to scrub that Server instance and make it squeaky clean before migrating.

Reducing technical clutter can improve your instance's overall maintenance and performance. Not to mention, cleaning up this tech debt will create a better experience for users because they won’t have to choose between multiple fields.

**Atlassian support for Server ends Feb. 15, 2024

How can we address this technical debt?

There are several ways to approach this task. I’m going to use two Appfire apps to help find and bulk remove unused configuration components.

How do we know If a configuration component is not being used?

• If a configuration component (i.e. Issue Type Screen Scheme) is not associated with a Jira project, then that component is not actively in use.

How do we know if a configuration component is associated with a project or not? I'm glad you asked. We’re going to use an app: Configuration Manager for Jira.

Configuration Manager for Jira (CMJ)

In my opinion, CMJ is a Data Center Jira admin's best friend. I work for Appfire, but I would love this app even if I didn’t. It’s like an admin's Swiss Army Knife. With CMJ you can:

• Migrate Jira projects to Cloud or other Data Center instances.

• Back up individual or all Jira projects.

• Display any configuration component along with dependencies.

• Perform deep integrity checks to individual or all Jira projects.

To find unused components, we can use the Power Admin functionality in CMJ. Power Admin lets you search on any configuration components.

You can then narrow your search down to those components that aren’t associated with any projects.

This will display all configuration components not associated with a project. From here, you can use CMJ to export this list to a CSV file.

With the CSV file exported and in hand, we can use that file to bulk delete the unused component using the Command Line Interface for Jira.

Command Line Interface for Jira (CLI)

CLI leverages Atlassian’s remote API to allow admins to perform migrations, automate tasks, and perform bulk actions.

With our CSV file generated from CMJ, we can use a CLI command to execute the deletion of these unused components.

Let’s break down the command:

Command	Description
dcprod	Instance to apply the command. Configured in the CLI properties file.
--action runFrom Csv	Indicating we will be using a CSV file
--file issueTypeScreenScheme.csv	Location of the CSV file
--options setReplacementVariables	Indicates variables will be passed in from the CSV file to the command
--common “--action deleteIssueTypeScreenScheme --id @[deleted]@”	Sub action to execute on the CSV file and specifies the variable to be replaced from the CSV file. In this case we execute the deleteTypeScreenScheme action using the ID passed in from the CSV file.
--continue	Continue to the end of the CSV file

Below is a 1 minute demo of the CMJ + CLI process in action.

CMJ plus CLI - Bulk delete unused components 

Recap

• Best practice is to ensure a clean and organized data center instance for migrations or general day-to-day administration.

• We used Configuration Manager for Jira’s Power Admin feature to find unused configuration components.

• We exported the list of unused components to a CSV file.

• We used Command Line Interface for Jira and CSV file to execute bulk deletions of the unused components.

If you have questions about any of the above, feel free to shoot me a message.

-Ed

[Robert Wen_Cprime_]

Having just taken the Governance and Housekeeping badge class, this offers some really good "next steps"!

[Rebekka Heilmann _viadee_]

We've done lots of manual clean up, especially streamlining configuration names and translations as our instance was/is a mix between English and German. We noticed, that cleaning up BEFORE migrating to Cloud is a lot easier as you still have access to the Database.

Deleting unused objects, standardising Workflows and Configurations and archiving old projects is making the move into Cloud so much easier!