Jira ist Turing-vollständig

 (seriot.ch)
2 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Jira Automation kann eine Minsky-Maschine mit zwei unendlichen Zählern und endlichen Befehlszuständen ausdrücken und damit die Turing-Vollständigkeit von Jira zeigen
  • Der Epic-Status dient als Programmzähler, die Anzahl verknüpfter Bugs und Tasks als zwei Register, und Automation-Regeln bilden die Dispatch-Tabelle pro Befehl
  • INC und DEC werden durch Erstellen bzw. Löschen verknüpfter Issues umgesetzt, und bedingte Verzweigungen werden über JQL-Bedingungsregeln entschieden, die die Zahl verknüpfter Issues prüfen
  • Das Additionsbeispiel startet mit A=2, B=3, reduziert Bugs und erhöht Tasks und erreicht bei der tatsächlichen Ausführung auf *.atlassian.net 5 Tasks sowie einen Haltzustand
  • Das Fibonacci-Beispiel verkürzt Schleifen durch die Umwandlung von Issue-Typen; wenn die Kettentiefe 10 von Jira Cloud erreicht ist, kann es durch manuelles erneutes Triggern weiterlaufen

Eine mit Jira Automation gebaute Minsky-Maschine

  • Jira Automation kann eine Minsky register machine mit zwei unendlichen Zählern und endlichen Befehlszuständen ausdrücken, wodurch sich eine Reduktion konstruieren lässt, die die Turing-Vollständigkeit von Jira zeigt
  • Das von Minsky 1967 bewiesene Modell besteht nur aus INC r; goto S und if r == 0 goto S else (DEC r; goto S')
  • Jira-Komponenten entsprechen den einzelnen Elementen der Minsky-Maschine
    • Register A: Anzahl verknüpfter Bug-Issues
    • Register B: Anzahl verknüpfter Task-Issues
    • Program Counter: Status eines einzelnen Epic-Issues
    • Dispatch Table: Jira-Automation-Regeln pro Befehlszustand
    • Clock: von der Automation ausgelöster Übergang oder externes erneutes Triggern nach Erreichen des Kettenlimits
  • Der Epic-Status kodiert den aktuellen Befehl, und Automation rules prüfen die Zahl verknüpfter Issues, um in den nächsten Zustand zu wechseln
  • INC und DEC werden durch Erstellen und Löschen verknüpfter Issues des jeweiligen Typs umgesetzt, bedingte Verzweigungen durch JQL-Bedingungsregeln

Ausführungsbeispiele und Einschränkungen

  • Das Additionsprogramm besteht aus einem Minsky-Programm, das A verringert und B erhöht 
    1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
  • Die Minimalimplementierung besteht aus einem Epic, fünf verknüpften Issues und je einer Automation-Regel pro Befehlszustand

  • Workflow und Regeln

    • Im Jira-Workflow werden der Anfangszustand BACKLOG und danach TODO, DEV, PROD angelegt, wobei Übergänge zwischen allen Zuständen möglich sind
    • Es wird ein Epic im Status BACKLOG erstellt
    • Die TODO-Regel implementiert DEC A; if A=0 halt, else goto DEV
      • Sie wird ausgelöst, wenn sich der Epic-Status auf TODO ändert
      • Wenn mindestens ein verknüpfter Bug vorhanden ist, wird ein Bug gelöscht und der Epic in DEV überführt
      • Gibt es keinen Bug, wird der Epic zum Anhalten nach PROD überführt
    • Die DEV-Regel implementiert INC B; goto TODO
      • Sie wird ausgelöst, wenn sich der Epic-Status auf DEV ändert
      • Sie erstellt einen neuen Task und verknüpft ihn mit dem Epic
      • Anschließend wird der Epic in TODO überführt
    • Bei beiden Regeln ist "Allow rule to trigger other rules" aktiviert

  • Initialwerte und Ergebnis

    • Der Epic wird mit zwei Bugs und drei Tasks verknüpft und damit auf A=2, B=3 initialisiert
    • Wird der Epic in TODO überführt, läuft folgende Kette ab 
      (2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
    • Das wurde auf einer tatsächlichen *.atlassian.net-Instanz ausgeführt; am Ende erreicht der Epic PROD, mit 0 Bugs und 5 verknüpften Tasks
    • Diese Ausführung berechnet mit Jira-Automation 2 + 3 = 5

  • Fibonacci-Aufbau

    • Convert Issue Type kann Issue-Typen sofort ändern, etwa Bug → Story oder Story → Task
    • CONVERT lässt sich als DEC + INC ausdrücken und erweitert die Rechenfähigkeit nicht, verkleinert aber die Dispatch-Tabelle für Verschiebungsschleifen und erleichtert dadurch komplexere Programme
    • Fibonacci wird als (A, B) → (B, A+B) ausgedrückt und besteht aus drei Registern A=Bug, B=Task, C=Story sowie drei Zuständen TODO, QA, DEV 
      TODO:
    if any linked Task exists:
        CONVERT Task → Story
        INC Bug
        transition to TODO
    else:
        transition to QA

QA:
    if any linked Bug exists:
        CONVERT Bug → Task
        transition to QA
    else:
        transition to DEV

DEV:
    if any linked Story exists:
        CONVERT Story → Bug
        transition to DEV
    else:
        transition to TODO
    • Der Anfangszustand ist A=1, B=1, C=0, und in B, also der Anzahl der Tasks, erscheint die Folge 1, 1, 2, 3, 5, 8, 13, ...
    • Anders als die Additionsmaschine hat die Fibonacci-Maschine keinen Haltzustand und läuft, bis die Kettentiefe 10 von Jira Cloud erreicht wird
    • Ist dieses Limit erreicht, kann ein Operator den Epic erneut triggern und die Ausführung fortsetzen; eine einzige Statusänderung startet die Kette erneut
    • Jira Data Center stellt automation.rule.execution.timeout und zugehörige Einstellungen als konfigurierbare Eigenschaften bereit
    • Unter der Annahme unendlicher Issue-Erzeugung und Regelausführung kann die Sprache von Jira Automation eine Zwei-Zähler-Maschine kodieren; nach dem üblichen Maßstab, dass auch physische Computer endlich sind, widerlegen die endlichen Quoten von Jira Cloud diese Konstruktion nicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Jira ist so vollständig furchtbar, dass es das Potenzial hat, sich in jede andere Form von Furchtbarkeit zu verwandeln

    • Jira ist das ultimative Beispiel für Entfremdung
      Hätte Marx Atlassian gekannt, hätte der Grundrisse lichterloh gebrannt
    • Das Schlimmste ist, dass alle Firmen, die Produkte für Arbeitsmanagement bauen, am Ende in Richtung Jira gehen
      Man muss nur GitHub Issues von 2014 mit dem heutigen Zustand vergleichen: https://github.com/features/issues
      Und sie fügen immer weiter, immer weiter duplizierte Features hinzu

  • Jira ist beliebt und hat auch gute API-Wrapper für die bevorzugte Sprache
    Es überrascht mich, dass unternehmensinterne Entwickler mit Hacker-Mentalität nicht den Großteil dessen, was Jira von ihnen verlangt, mit Python-Command-Line-Skripten oder Ähnlichem automatisiert haben
    Wenn ich es um mehr als eine Größenordnung einfacher nutzbar machen kann als die Leute, die mir Jira aufzwingen, kippt das Kräfteverhältnis, und Jira wird zu einem Tool, das man zu seinem eigenen Schutz vor sich herschiebt
    Ich habe Jira gelegentlich fast böswillig benutzt, und zur Absicherung von Zuständigkeiten ist es hervorragend
    Wenn etwas schiefläuft, kann man sagen: „Das stand alles ganz klar in den Hunderten von Jira-Updates, die ich geschrieben habe, und ihr habt sie doch gelesen, oder?“
    Jetzt gibt es auch noch AI, also kann man alles mit Custom-Skripten zusammenbinden und die AI die Jira-Drecksarbeit erledigen lassen

    • Ziemlich viele Leute haben das bereits getan, aber das Problem ist, dass jede Jira-Instanz eine fraktale Schneeflocke aus Custom-Properties ist, in der sich alte gescheiterte Migrationen und neue Organisationsstrategien schichtweise ablagern
      Oft kann die API Dinge tun, die die UI nicht erlaubt, und weil sich alle an der UI orientieren, landet man in seltsam kaputten Ecken
      Zum Beispiel bemerkt man vielleicht nicht, dass custom_field_5537 mit custom_field_442 gepaart werden muss, damit es im Dashboard anderer Leute erscheint
      Und custom_field_10995 behauptet, ein Integer-Feld zu sein und wird in XML auch als Integer zurückgegeben, aber beim Erstellen eines Vorgangs muss man einen undokumentierten magischen Konstanten-String verwenden, während das beim Aktualisieren wieder nicht nötig ist
      Die Web-UI macht das nicht so, und in HTML und Requests steht einfach ein Integer, während nur 80 % des Strings mit dem angezeigten Dropdown-Text übereinstimmen
      Jira-Automatisierung war die schlimmste Programmiererfahrung, die ich je hatte
      Einfachere Setups gibt es sicher, und die mögen sogar ziemlich leicht sein, aber es ist trotzdem zu krass
      Traurigerweise ist der Aufwand immer noch absolut lohnend. Klare Empfehlung
    • An einem früheren Arbeitsplatz habe ich mehrere Tools gebaut, die per API Zeit gespart haben, und das waren alles kleine Shell-Skripte
      Wir haben jedem Ticket ein Custom-Textfeld für eine menschenlesbare Beschreibung hinzugefügt, und wenn ein Release ausgerollt wurde, hat das Deployment-Skript automatisch den Zeitstempel eingetragen
      Wir haben pro Arbeitseinheit jeweils genau ein Ticket released und an einem Tag oft mehrere Tickets verarbeitet
      In Kombination mit Custom-Filtern lieferte Jira für jedes Board und für die ganze Firma menschenlesbare Changelogs, und diese Nachrichten wurden an die Business-Seite in Slack weitergeleitet, sodass alle wussten, was ausgerollt wurde
      Es war auch ein durchsuchbares Release-Audit-Log, verknüpft mit Code-Änderungen
      Der Deployment-Prozess hat auch den Status der Jira-Tickets umgestellt, sodass Entwickler Tickets nur in main mergen mussten und sie dann ausgerollt und in Jira abgeschlossen waren
      Es gab auch viele kleine Skripte, die Tickets für wiederkehrende Aufgaben automatisch erzeugten
      Das war über Jahre sehr robust und läuft wahrscheinlich noch heute
      Die Benennungskonvention für Custom-Felder war nicht besonders gut, aber wenn das Team die Jira-Konfiguration unter Kontrolle hat, ist es nicht schwer, einen einheitlichen Standard beizubehalten
      Anfangs mochte ich Jira nicht, und früher hatte es viele Probleme, aber heute ist es bei guter Einrichtung gar nicht so schlecht
      Für meine eigene Firma würde ich es nicht wählen, aber aus der Perspektive eines Entwicklers, Managers, Endnutzers und internen Tool-Entwicklers gilt: Wenn es einmal konfiguriert ist und läuft, steht es einem meistens nicht im Weg
    • „Alles mit Custom-Skripten zusammenbinden und die AI die Jira-Drecksarbeit machen lassen“ klingt so, als wäre Jiras Aufgeblasenheit noch nicht groß genug
      Wenn man noch mehr Text hinzufügt, wird Jira somehow über all diesem Text immer alles automatisch ausführen und dadurch nur noch langsamer werden
      Wenn eure Firma Heizung braucht, benutzt einfach Jira
    • Wir sind schon vor sehr langer Zeit zu JetBrains YouTrack gewechselt, und dafür nutzen wir die API genau für solche Dinge
      Ziemlich flexibel, und dank AI hat sich da noch mehr geöffnet
    • Unsere ganze Firma läuft faktisch auf Jira
      Die meisten Prozesse hängen an Jira, und bestimmte Übergänge lösen Webhooks für Automatisierungen aus
      Eines der ersten Dinge, die ich getan habe, nachdem ich AI-Zugriff bekommen hatte, war, ein Jira MCP zu bauen
      Jetzt versuche ich, Jira fast gar nicht mehr direkt anzufassen, und lasse Claude Jira-Issues erstellen, Kommentare schreiben, Unteraufgaben anlegen, Issues verknüpfen usw.
      Früher hatte ich jedes Mal Angst, wenn ich untersuchen musste, wie man etwas umsetzt und es in Aufgaben zerlegt
      Denn je feiner ich es aufgeteilt habe, desto mehr Jira-Issues musste ich für die einzelnen Aufgaben anlegen
      Jetzt schreibe ich einfach alles in eine Datei und überlasse die Jira-Drecksarbeit dem Large Language Model

  • Als ich zu einem Ort zurückkehrte, an dem ich früher gearbeitet hatte, wurde dort immer noch JIRA verwendet.
    Im Bewerbungsgespräch habe ich natürlich gesagt: „Ach, JIRA, benutzt ihr das immer noch? Klar, kann ich.“
    Tatsächlich kann ich es benutzen, aber als ich das aktuelle JIRA sah, war ich wirklich schockiert.
    Es gibt ungefähr tausend kleine Ärgernisse, und eines der schlimmsten ist, dass das Feld plötzlich in den Bearbeitungsmodus springt, wenn man Text per Doppelklick auswählen will.
    Ich kannte noch JIRA Server 4.0, und hier kann man in Erinnerungen schwelgen: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
    Wenn man weit genug hineinzoomt, sieht man bei jedem Issue Titel, Typ, Fix-Version, betroffene Version usw., und es ging direkt in die Kommentare über. Sehr simpel.

    • Dass ein Doppelklick in den Bearbeitungsmodus springt, stimmt wirklich.
      Das ist unglaublich nervig. Sie bekommen nicht einmal grundlegende Textbearbeitung richtig hin.
      Aber irgendein Projektmanager meinte, er würde das mögen.
      Angeblich, weil er zum Auswählen ganzer Wörter kein Doppelklick-Ziehen benutzt.
      Wie immer werden geübtere Nutzer für die Bequemlichkeit von Leuten ausgebremst, die mit Computern gerade so klarkommen.
    • Die Reaktion „JIRA, benutzt ihr das immer noch?“ klingt seltsam.
      Da frage ich mich, ob ich etwas verpasst habe oder in ein Zeitloch gefallen bin.
      Ich verstehe nicht, warum über Jira gesprochen wird, als wäre es Visicalc.
      Ich arbeite inzwischen nicht mehr in einer IT-Firma, also habe ich in den letzten zwei Jahren vielleicht einen großen Umbruch verpasst.
    • Man kann die Korrelation zwischen Aktienkurs und positiver Nutzerwahrnehmung in den Jahren finden, in denen das Produkt noch gepflegt wurde.
      Beim Übergang von 4.x zu 6.x kamen auch die kleinen Ärgernisse dazu, wie bei OFBiz mit den klapprigen Kästen und völlig anderen Produkten, deren Oberfläche nur äußerlich angepasst wurde.
      Diese Ingenieure sind längst weg, und die 280 Dollar pro Aktie haben sie gleich mitgenommen.
    • Ich muss Jira oder ähnliche Tools in meinem eigentlichen Job jetzt nicht mehr benutzen, deshalb frage ich mich ehrlich: Gibt es aus Sicht des gesamten Projektteams, nicht nur der Entwickler, irgendeinen Konsens über bessere Alternativen?
    • Auch diese Version von JIRA konnte bei schlechter Konfiguration leicht furchtbar werden.
      Das Kernproblem von JIRA ist, dass die Rechte für eine vernünftige Konfiguration immer nur bei wenigen Leuten liegen, und diese Leute entweder keine Lust haben, keine Zeit haben oder sich nicht dafür interessieren, weil sie es nicht täglich benutzen.
      Natürlich ist das nicht das einzige Problem.
      Es ist unvorstellbar langsam, und es gibt seltsame Einschränkungen wie die, dass ein Issue nicht das Parent eines anderen Issues sein kann.

  • JIRA ist viel zu langsam, und die Administratoren wirkten immer, als wüssten sie nicht, wie man es richtig konfiguriert.
    Allein vom Benutzen habe ich schon Traumata.

    • Man kann argumentieren, dass das nicht die Schuld des Tools ist.
      Auf diesem Planeten gibt es einfach keinen einzigen Menschen, der dieses Tool korrekt konfigurieren kann.
      Man kann dem Tool wohl kaum die menschliche Unfähigkeit anlasten.
      Für wen es dann eigentlich gebaut wurde, ist allerdings eine ganz andere Frage, die wir jetzt besser nicht diskutieren.
    • Was mich immer stört, ist die Langsamkeit.
      Im Kern ist ein Ticket-System nicht mehr als eine Datenbank mit Tickets, Beziehungen zwischen Tickets und Zuständen.
      Natürlich kann die Komplexität explodieren, wenn es viele verknüpfte Tickets, Custom Fields und Plugins gibt.
      Trotzdem verstehe ich nicht, wie etwas, das im Wesentlichen nur einfache Textdaten und Anhänge verarbeitet, so unerträglich langsam sein kann.

  • Endlich kann man in Jira Doom spielen.

    • Stimmt. Quake 3 Arena Multiplayer geht auch.

  • https://mattrickard.com/accidentally-turing-complete

  • Damit ist also erklärt, warum man bei manchen Jira-Tasks nicht entscheiden kann, ob sie anhalten oder nicht.

    • Fällt das dann unter „Man kann Doom in Jira spielen“?
      Liefert Jira auch eine Pumpgun, um die Dämonen zu töten, die daraus entstehen?

  • Benutz stattdessen mal Azure Boards, dann wirst du JIRA lieben.
    Denn es gibt keine Software auf der Welt, die Microsoft nicht noch schlechter machen könnte.

    • Ich habe Gmail schon immer gehasst und hasse es immer noch, aber nachdem ich letztes Jahr den Job gewechselt habe und meine neue Firma Outlook benutzt, habe ich meine Meinung geändert.
      Es ist schwer, Worte zu finden, die meine Verachtung für Outlook angemessen ausdrücken, und mit „ich mag es nicht“ fängt es nicht einmal an.
      Schon die grundlegendsten Aufgaben rund ums Empfangen und Senden von E-Mails überfordern es.
      Ich bekomme eine E-Mail-Benachrichtigung aufs Handy, öffne die App, und da ist nichts; ich ziehe zum Aktualisieren nach unten, und es passiert ebenfalls nichts.
      Meistens taucht sie erst 1 bis 15 Minuten später auf.
      Alles, was man in Outlook macht, ist absurd umständlich.
      Ich habe Outlook schon früher zu Office-2003-Zeiten benutzt, aber ich kann mich nicht erinnern, dass es damals so schlecht war. Ich weiß nicht, wie es so weit zurückfallen konnte.
      Von Teams will ich gar nicht erst anfangen. Ich weiß nicht einmal genau, welches Problem dieses Programm eigentlich lösen soll.
      Freigegebene Dateien liegen in OneDrive, aber auch in Teams und irgendwie auch in Outlook.
      Ich musste die Backup-Dateien meines Computers, etwa 30 GB an CloneZilla-Images, nach OneDrive/Teams/Outlook verschieben, und das dauerte ewig, während der Lüfter meines 6-Core-Ryzen-Laptops mit Win11 die ganze Zeit wie verrückt lief.
      Wie? Warum?

  • Alle Workflow- und Orchestrierungs-Engines sind turing-vollständig.
    Denn ihr eigentlicher Zweck ist es, Ausführungsabläufe zu automatisieren.

    • Bei wie vielen davon kann etwas unendlich weiterlaufen?
      Oder ein Mensch kann es erneut triggern und es ab der Stelle fortsetzen, an der es aufgehört hat?
    • Das denke ich nicht.
      Erstens ist JIRA keine Orchestrierung.
      Zweitens besteht die Aufgabe eines Workflows darin, irgendeinen Zustand mit externen Informationen zu verknüpfen und diese leicht manipulierbar zu machen.
      Um turing-vollständig zu sein, braucht man Trigger und Regeln, etwas wie einen unendlichen Zähler, zwei Stacks oder ein bidirektionales Band.
      Beweis mir das Gegenteil.

  • Ich mag die Jira-Automatisierung.
    Wenn ich in ein neues Team komme, das Jira benutzt, richte ich Automatisierungen ein, die die Story Points von Subtasks automatisch aufsummieren und in die Story Points des Parent-Issues eintragen oder Tickets automatisch zurück ins Backlog verschieben, wenn ihnen nicht genügend verfeinerte Eigenschaften fehlen.
    Zum Beispiel wenn Zuständiger, Story Points, Priorität oder Beschreibung fehlen.
    Nach nur einem Sprint ist das Team-Board schon deutlich aufgeräumter.
    Ich weiß nicht, warum das nicht der Standard ist, aber per Automatisierung lässt es sich leicht beheben.

    • Warum muss ein Zuständiger zugewiesen sein, damit ein Ticket als verfeinert gilt?
      Der Zuständige sollte doch die Person sein, die sich die Arbeit schnappt; das sollte kein Teil der Verfeinerungsphase sein.