Change is required. Atlassian engineer's blog

  Maintaining a clean and efficient Jira installation, especially in an On-Prem setup, involves meticulous data management. A common issue faced by administrators is the duplication of history records for assets in Jira, which can lead to database bloat and performance issues. Duplications often stem from situations such as stuck imports, automated processes running recursively, or incorrect manual imports. This article will guide you through the process of detecting and cleaning up duplicated records, with an emphasis on solutions contributed by the Jira community. Understanding the Issue Duplicated history records can severely impact the performance of your Jira instance. As history records accumulate, database queries slow down, and system memory usage increases disproportionately. In one notable case, duplications reached a staggering 52 million records, prompting an urgent need for cleanup. Detecting Duplicated Records Artem Tumanov, a valuable contributor to the Jira communit...

  Hello community,    Today, I would like to share a small snippet sql request to cleanup Insight object histories.  In the future, I will be happy to see the configuration in the Insight app as a retention policy. ( Please ,  Atlassian  provide retention policy feature in Insight)   We have 2mln+ objects in Insight, not so far, at the moment we do a cleanup and review existing potential weaknesses and improve performance of our Jira Service management DC setup.  Once our web navigation Insight tab was slow, If we do cleanup of history it starting to be fast then do review of records.  Every night our system syncs up with SAP, IdP and other external systems, also, event based sync up and updates objects from remote systems.  Therefore potential weakness is duplicated history, because change log we don’t need to keep longer than 3 months, as change log keeps on master systems.  Also, the next query helpful to find misconfigs.  S...

  Hi! Today I would like to share a possible way to migrate or merge a custom field during a periodical cleanup.  Possible ways are built-in functionality of Scriptrunner or myGroovy, own code and own yet another alternative way for the complicated situation. Also,you can follow with next typical steps of cleanup process: Detect the fields Create a ticket about merge plan  Detect the JQL, agile boards queries via database queries in tables searchrequest, add info into ticket Prepare the optimized the context in the comment of ticket Notify project stakeholders in the Jira ticket Get approvals  Inform via slack (email) the next merge the end users affected  for  that changes Execute the action. This is my typical process for the cleanup activity. As an  example , let’s do the next real case with screenshots.   Goal: Migrate from the  Production environment  field to  Products  field. Both fields are pickers.  Where some of ...

  Hi awesome community!    So automated housekeeping is good. If you want you can checkout ( Cleanup-Jira-Part-1 ,  Cleanup-Jira-2, ) Today, I would like to share use cases related to the cleanup Agile boards related stuff. So to make the continuous cleanup I just use the groovy code, which is can be run on any app with support groovy like Scriptrunner, myGroovy, Grooviouli.  Let’s start it. Use case #1 : Users are experimenting with Agile boards, own private boards, sometime you do migration. Then once your sprint reports shows incorrectly, where filters shows interesting things. Please, see below screenshot: Action : Let’s remove  Future  Sprint data in Closed issues. String jqlSearch = 'Sprint in futureSprints() and status in (Closed, Done) ' SearchService.ParseResult parseResult = searchService.parseQuery(loggedInUser, jqlSearch) if (parseResult.isValid()) { def searchResult = searchService.search(loggedInUser, parseResult.getQuery(), PagerFi...

  Hi awesome community,    Time to time we do many reports, also, our Bamboo instance grows so faster.  But we need to provide a high-performance service and make reports based exist build results because DevOps metrics are core for the release management. So let's investigate how we can do a cleanup and reduce our spaghetti code for the report collecting purpose.   1. Let's check what kind of status do we have? Successful, Failed, Unknown ( means Currently running), Unknown - something wrong, Incomplete. 2. I mean the grey one result, if you click you will like this info It's incomplete status.  About the unknown result, no worry it will not be removed if it's currently running a job. You can test and further investigate using that article: https://confluence.atlassian.com/bamkb/how-to-find-currently-running-jobs-900800506.html   3. How we can remove build result ?  Use that path for remove build result.   /build/admin/deletePlanRe...