Jira Cleanup – Part 1: Quick Wins

Jira Cleanup: Übersicht

Die Komplexität des administrativen Bereichs in Atlassian Jira wächst ganz natürlich mit ihrer Instanz und deren Anforderungen. Nach ein paar Jahren sammelt sich so einiges an. Das sorgt nicht nur für Verwirrung unter Administratoren, sondern führt auch zu Performance-Problemen.

Atlassian selbst hat die Notwendigkeit für einen regelmäßigen Jira Cleanup bei größeren Instanzen aufgegriffen und für Data-Center-Instanzen unterstützende Funktionalität hinzugefügt.

• Jira/JSM ab Version 7.10/3.10 Archive old projects
• Jira/JSM ab Version 8.4/4.4 Archive old issues
• Jira/JSM ab Version 8.16/4.16 Custom Fields Management
• Jira/JSM ab Version 8.18/4.18 „Clean up“ Admin Settings Page

Cleanup Vorbereitung

Bevor es richtig losgeht, sollte der Ist-Stand der Jira-Instanz genauer betrachtet werden. Dies hilft dabei, Problembereiche zu identifizieren und nach dem Cleanup Verbesserungen zu erkennen. Um die Anzahl der einzelnen administrativen Elemente nicht einzeln heraussuchen zu müssen, haben wir in Jira Cloud eine kleine App gebaut, die derzeit gratis vom Atlassian Marketplace zu installieren ist. Die App zeigt auf Knopfdruck die Anzahl aller administrativen Elemente. Diese Werte werden gespeichert, womit in der Tabelle auch die Differenz zum letzten Messpunkt angezeigt werden kann.

Cleanup Abschnitte

1. Entfernen aller ungenutzten administrativen Elemente.
2. Zusammenführen gleicher oder zu ähnlicher administrativer Elemente.
3. Etablierung von skalierbaren Default-administrativen Elementen, die zukünftig als Grundlage für neue administrative Elemente dienen.

In diesem Blogpost möchten wir das Vorgehen für den ersten Abschnitt aufzeigen.

Cleanup Quick Wins: Entfernen ungenutzter Elemente

Das Entfernen ungenutzter administrativer Elemente hat einen entscheidenden Vorteil. Solange wir die ungenutzten Elemente korrekt identifizieren, hat das Entfernen keinen Einfluss auf die aktiv genutzte Funktionalität in Jira. Dadurch können wir in diesem ersten Abschnitt eines Cleanups schnell viel erreichen, um den administrativen Bereich unserer Jira-Instanz um Ballast zu erleichtern.

In welcher Reihenfolge soll ich vorgehen?

In der Administration von Jira gibt es viele Abhängigkeiten, die man kennen muss, um Auswirkungen von Veränderungen in administrativen Elementen abschätzen zu können. Um ungenutzte Elemente identifizieren zu können, betrachten wir diese Abhängigkeiten des Elements.
Zum Beispiel betrachten wir, ob ein Workflow einem Workflow Scheme zugewiesen ist. Falls dies nicht der Fall ist, können wir sicher sein, dass der Workflow in keinem Projekt verwendet wird. Folglich müssen wir aber zuerst alle ungenutzten Workflow Schemes löschen, bevor wir alle ungenutzten Workflows finden können.
Einen Überblick über Abhängigkeiten administrativer Elemente bietet die folgende Grafik, die wir bei codecentric auch für Admin-Schulungen in Jira einsetzen.

Ausgehend von unseren Erfahrungen empfehlen wir die folgende Cleanup-Reihenfolge.

1. User
2. Projekte
3. Permission Schemes
4. Issue Type Schemes →  Issue Types
5. Workflow Schemes→ Workflows → Statuses
6. Issue Type Screen Scheme → Screen Schemes → Screens
7. Field Configuration Schemes → Field Configuration → Custom Fields
8. Project Roles

Andere Cleanup-relevante Bereiche können im Nachhinein ohne weitere Abhängigkeiten angegangen werden.

Exemplarisch möchten wir nun in ein paar Beispielen zeigen, wie wir ungenutzte Elemente identifizieren können.

Wie identifiziere ich ungenutzte Elemente?

Diese Frage ist für jedes administrative Element individuell zu beantworten. An einigen Beispielen möchten wir die notwendigen Schritte aufzeigen.

Ungenutzte Projekte identifizieren

1. Jira Administration → Projects → Projects
2. Sortiere die Tabelle nach „Last issue update“
3. Suche nach „–“ und „Last issue update“ > 6 Monate

a. „–“ Bedeutet, dass das Projekt keine Issues beinhaltet.
b.„Last issue update > 6 Monate“ bedeutet, dass keine Issue-Updates innerhalb der letzten sechs Monate vorgenommen wurden.

4. Sortiere die Tabelle nach „Issues“

5. Suche nach Projekten mit weniger als ~10 Issues.

6. Die genannten Umstände (keine Issues, <10 Issues, keine Issue Updates innerhalb von 6 Monate) legen nahe, dass die Projekte inaktiv sind und gelöscht werden können. Sicherheitshalber sollte vor dem Löschen trotzdem immer zuerst der Projekt-Lead kontaktiert werden.

Alternativen zum Projektlöschen

Projekt-Archiv

Die Funktionalität, Projekte zu archivieren, ist nur in Jira Cloud (Premium, Enterprise) und Jira Data Center vorhanden.

Wer diese Funktionalität hat, kann Projekte unkompliziert für normale Nutzer entfernen und diese jederzeit mit allen Konfigurationen wiederherstellen. Dies ergibt Sinn für alle Projekte, bei denen nicht auszuschließen ist, dass diese wieder relevant werden.

Wer die Funktionalität des Projekt-Archivs außerhalb der genannten Installationen nutzen möchte, kann diese über einen Workaround simulieren.

1. Erstelle ein Permission Scheme, in dem keine Permissions vergeben werden.
2. Erstelle eine Projektkategorie „Archiviert“
3. Weise den Projekten das Permission Scheme und Projektkategorie zu.
4. Notiere dir, welches Permission Scheme ursprünglich zugewiesen war und stelle sicher, dass dieses nicht aus Versehen gelöscht wird, da dieses nun keinem Projekt mehr zugewiesen sein könnte.

Projekt-Trash

Ähnlich verhält es sich bei Projekt-Trash. Die Möglichkeit Projekte in einen Trash zu verschieben, indem sie automatisch nach 60 Tagen gelöscht werden, ist nur in Jira Cloud verfügbar. Wer diesen Sicherheitszeitraum beim Löschen von Projekten simulieren möchte, kann auch hier ein eigenes Permission Scheme anlegen, in dem keine Permission vergeben wurden und eine Projektkategorie „Trash“ einführen. Dadurch verschwindet das Projekt für alle normalen Nutzer. Das Projekt nach 60 Tagen löschen muss man aber selbst.

Ungenutzte Issue Type Screen Schemes, Screen Schemes und Screens identifizieren

Ein gutes Beispiel für die notwendige Reihenfolge beim Cleanup bietet der Bereich der Screens. Da beim Erstellen eines jeden neuen Projekts ausgehend von einem Jira Template automatisch neue administrative Elemente angelegt werden, ist dieser Bereich sehr häufig überfüllt von Elementen, die nicht automatisch beim Löschen von Projekten wieder mit gelöscht werden.

Wir fangen an mit „Issue Type Screen Schemes“.

1. Jira Administration→ Issues → Issue Type Screen Schemes
2. Jedes Issue Type Scheme, das keinem Projekt assoziiert ist, ist ungenutzt und kann folglich gelöscht werden. Folglich ist es sinnvoll, vor diesem Schritt ungenutzte Projekte zu löschen.Anschließend „Screen Schemes“
3. Jira Administration→ Issues → Screen Scheme
4. Auch hier können alle Screen Schemes gelöscht werden, die keinem „Issue Type Screen Schemes“ zugewiesen sind.Abschließend „Screens“
5. Jira Administration → Issues → Screens
6. Gelöscht werden können alle Screens, die weder Screen Scheme noch Workflow zugewiesen sind. Folglich empfehlen wir in der oben genannten Reihenfolge zuerst ungenutzte Workflows zu löschen, bevor Screens angegangen werden.

Das Einhalten der korrekten Reihenfolge beim Löschen von ungenutzten Elementen reduziert den Aufwand beim Cleanup beträchtlich.

Ungenutzte Custom Fields identifizieren

Seit Data Center Version 8.16 in Jira bzw. 4.16 in Jira Service Management sowie in Cloud bietet Jira die notwendige Funktionalität, ungenutzte Custom Fields mit geringem Aufwand identifizieren zu können. Cleanup-Interessierten würden wir nahelegen, die Versionen abzuwarten, bevor Custom Fields angegangen wird.

1. Jira Administration → Issues → Custom Fields
2. Sortiere die Tabelle nach Cloud „Last update“, (DC) „Last value update“
   → (Cloud) No information, (DC) Never: Bedeutet, das Custom Field beinhaltet keine Daten, womit es entweder neu ist oder nie genutzt wurde.
   → „Last update“ älter als sechs Monate: Indikator, dass das Custom Field nicht mehr genutzt wird
3. Suche nach Custom Fields, die keinen Screens zugewiesen sind
   → Keinen Screens zugewiesen zu sein, ist ein Indikator für ungenutzte Custom Fields. Es sollte aber auf jeden Fall mit einem Stakeholder gesprochen werden, da das Custom Field für interne Zwecke benutzt werden könnte und bewusst nicht den Usern über Screen ersichtlich gemacht wurde.

Custom Field Stakeholder ermitteln

Da Custom Fields nie einfach gelöscht werden sollten, ist es ratsam, Personen ausfindig zu machen, die über die angedachte Verwendung der Custom Fields Bescheid wissen.

1. Ersteller des Custom Fields ermitteln
   1. Jira Administration → System → Audit Log
   2. Suche nach Summary: „Custom field created“ und Freitext „“
2. Projekt-Lead über Projekt ermitteln
   1. Eventuell ist Custom Field Context auf ein Projekt beschränkt
   2. Eventuell ist das Custom Field einem Projekt-spezifischen Screen zugeteilt
   3. Falls Issues mit Daten im Custom Field existieren, können mit der JQL-Suche „ is not EMPTY“ ein oder mehrere Projekte ermittelt werden, in denen das Custom Field Verwendung fand.

Ausgehend vom Projekt kann der Projekt-Lead ermittelt werden. Dieser sollte über die angedachte Verwendung des Custom Fields Auskunft geben können.

Custom Field Trash

Um zu verhindern, dass Custom Fields und deren Daten fälschlicherweise gelöscht werden, verfügt Jira Cloud über eine Custom-Field-Trash-Funktionalität. Darin werden Custom Fields automatisch nach 60 Tagen gelöscht. Während dieser Zeit verschwinden die Custom Fields aus dem System, können aber mit allen Daten wiederhergestellt werden, falls dies nötig sein sollte.

Workaround Custom Field Trash für Server/Data Center

Den Zustand eines Custom Fields im Trash können wir in Server/Data Center simulieren, indem wir den Field Context von Global auf ein spezifisches Projekt einschränken. Das Projekt sollte eines sein, auf das normale Benutzer keinen Zugriff haben.

Dadurch verschwindet das Custom Field für alle normalen Nutzer. Trotzdem kann das Custom Field problemlos mit allen Daten wiederhergestellt werden, indem man den Field Context wieder zurück auf Global stellt. Das Custom Field nach den 60 Tagen löschen müssen wir hier allerdings selbst.

Ausblick

Im nächsten Blogpost betrachten wir, wie man gleiche administrative Elemente zusammenführt, ohne die Funktionalität der Instanz zu gefährden.

Gerne unterstützen wir euch in eurem Jira Cleanup auch als Atlassian Consultants.