Viele Software Unternehmen verwenden Jira, um ihre Aufgaben, Fehler, Verbesserungswünsche (Tasks, Bugs, Improvents) ihrer Software festzuhalten. Es ist eine nette Platform, in der man unter anderem durch Zusatz diverser Add-ons die Entwicklung planen und den Fortschritt messen bzw. graphisch darstellen kann.
Das interessanteste ist jedoch, daß man jeden Entwicklungsschritt für jedes Unternehmen individuell konfigurieren kann.
Möchte jemand zum Beispiel zu den Bearbeitungsschritten eines Fehlers zusätzlich zu den Stati “Offen”, “In Arbeit” und “Entwickelt” einen “Test” Status haben (den Arbeitsablauf der Entwicklung ein wenig modifizieren), dann bitte, einfach konfigurieren. Möchte jemand bei den einzelnen Bearbeitungsschritten zusätzlich eine Priorität angeben können, dann bitte, einfach ein neues Feld (“Custom Field”) hinzufügen und evtl. einen Standardwert setzen.
Hier ist das Problem
Und hier ist schon das Problem. In der Jira Version 4.3.3 ist das Datenbank Modell noch stark ausbaufähig, Primärschlüssel sind die dahinterliegenden Werte anstatt fortlaufenden Nummern. Der voreingestellte Wert des “Custom Fields” wird in eine genericconfiguration-Tabelle als Fremdschlüssel in XML-Notation mit Variablentypvorgabe geschrieben, z.B. beim Feld Priorität wird der Wert “astronomisch hoch” als “
Ab Jira Version 5 hat man diesen Mangel teilweise erkannt und ebenso teilweise behoben. Jede Tabelle hat einen ordentlichen Primärschlüssel bekommen. Jetzt fragt sich der geneigte Leser: “Wieso denn teilweise?” Na weil hier und da das Fremdschlüssel-Feld immer noch den Typ String hat und die Fremdschlüssel werden nach wie vor in XML-Notation wie z.B. wie folgt reingeschrieben: “
Richtiges Datenbank Modell bitte?
Wenn man schon Java benutzen muß, hätte man ein richtiges Datenbank Modell schon der Performance wegen erstellen können. Einen String jedes Mal zu lesen, zu zerlegen und den Feldtyp zu erkennen dauert im Betrieb jedes Mal sehr viel länger als einfach einen richtigen Feld-Typ zu erwarten. Ja, es kostet mehr Entwicklungsaufwand, weil die Entwickler plötzlich eine richtige Architektur haben, viele kostspielige Fehler der Vergangenheit ausbügeln UND plötzlich aus ihrem Kämmerchen herauskommen und mit anderen Entwicklern arbeiten müssen. Und ja, es muß bis in die Untiefen der Software getestet werden! Ja und? Ihr wollt doch keinen ungetesteten Blödsinn verkaufen, oder?!? Jede “schnell-schnell” und/oder “ist nur mal zum testen und plötzlich in Produktion” Aktion, jeder nicht sofort begradigte Fehler kostet das Unternehmen im Nachhinein das Vierfache!
Nun ja, wie mannigfaltig die Gründe auch sein können eine richtige Architektur zu entwickeln bzw. die alte zu verbessern, die Weisen aller Weisesten bei Atlassian wussten es einfach besser. Es ist immerhin eine Verbesserung zu vorher, eventuell kommt die Einsicht noch.
Hail to usability improvements!
Wirklich schön ist, daß man im Zuge des Upgrade Prozesses daran gedacht hat alle Jira-eigenen Tabellen so zu modifizieren, daß alle Fremdschlüssel zu den neuen Primärschlüsseln passen (Es klappt nicht immer, einen Clone der Jira Instanz mit der alten Version zu haben ist goldwert. Für Upgrade Versuche sowieso. Hail to the Jira-Clone!). Soweit so gut, Upgrade von Version 4.3.3 auf Version 5.x (in meinem Fall Jira Version 5.2.5) verläuft problemfrei. Jira kommt sogar hoch, man kann sich im neuen und schönen System wunderbar bewegen, die vielen neuen sehr sinnvollen und lange vermissten Verbesserungen, von denen man manchmal sogar selbst nicht wußte, daß man sie dringend braucht, ausprobieren. Die Konfiguration der Projekte, Felder usw. ist deutlich einfacher und schöner. Usability++
Upgrade tut so als ob alles glatt lief
Das geht alles so lange gut, bis man versucht sich eine neue Aufgabe bzw. einen neuen Task anzulegen. Man füllt alle Felder aus, überdenkt sie und klickt dann auf “Create”. Und nichts passiert. Absolut gar nichts. In den Log-Dateien wird sich über den unverschämten Versuch aufgeregt einen String-Datentyp als Long-Datentyp auszugeben. Was? Woher? Weniger Aussagekraft kann man einer Fehlermeldung nicht zuweisen? Was ist das? Ist das Python mit den sinnlosesten Fehlermeldungen überhaupt oder was?!? Weiß denn keiner wie man einen sinnvollen “catch” in einem try-catch Block schreibt?!? Tja, nachdem man sich etwas beruhigt hat und das Hirn wieder anfängt zu arbeiten, fragt man sich was nun?
Man fragt selbstverständlich das FAQ der Atlassian Seite. Es sagt Dir nur: “Ja, sieht nach einem Custom Field aus, da musst es in der Datenbank suchen und da was löschen”. Voller Entsetzen schaust Du Dir Deine zwei Milliarden selbst erstellte Felder an, fängst an zu zucken und fällst fast in Ohnmacht. Ja, welches denn? Kann man den Störenfried nicht einfach so identifizieren und zu Mitarbeit zwingen? Kann jawohl nicht wahr sein! Hätte man das nicht gleich bei der Datenbank Modifikation im Zuge des Upgrade Prozesses korrigieren können?!? Bei allen anderen Feldern wurde es ja ebenfalls gemacht!
Die Lösung
Um ehrlich zu sein, man kann! Aber warum muß ich die Lösung finden, obwohl ich damit nichts zu tun habe?
delete from genericconfiguration
where datakey in (select id
from fieldconfiguration
where fieldid like 'customfield%');
Nachtrag
Ok, so sanft ist das Upgrade doch nicht verlaufen. Recht viele customfieldoption Felder haben immer noch einen String-Primärschlüssel aus der vorherigen Jira Version anstatt eines richtigen Primärschlüssels. Wieso ist das Feld eigentlich immer noch ein varchar-Feld, wenn da nur Fremdschlüssel stehen müßten? Ah, verstehe, weil man die Migration sauber durchführen müßte. :-/