Jira est Turing-complet

(seriot.ch)

2 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp

Jira Automation peut représenter une machine de Minsky avec deux compteurs infinis et un ensemble fini d’états d’instruction, ce qui permet de montrer la complétude de Turing de Jira
L’état d’un Epic sert de compteur ordinal, et le nombre de Bug et de Task liés devient les deux registres, tandis que les règles Automation forment la table de dispatch pour chaque instruction
INC et DEC sont implémentés par la création et la suppression d’issues liées, et les branchements conditionnels sont décidés via des règles conditionnelles JQL qui vérifient le nombre d’issues liées
L’exemple d’addition part de A=2 et B=3, diminue les Bug et augmente les Task, puis atteint 5 Task et un état d’arrêt sur une exécution réelle sur *.atlassian.net
L’exemple de Fibonacci réduit les boucles grâce à la conversion de type d’issue et, lorsqu’il atteint la limite de profondeur de chaîne de 10 sur Jira Cloud, il peut continuer via un redéclenchement manuel

Machine de Minsky construite avec Jira Automation

Jira Automation peut représenter une machine à registres de Minsky avec deux compteurs infinis et un ensemble fini d’états d’instruction, ce qui permet une réduction montrant la complétude de Turing de Jira
Le modèle démontré par Minsky en 1967 ne se compose que de INC r; goto S et if r == 0 goto S else (DEC r; goto S')
Les composants de Jira correspondent chacun à un élément de la machine de Minsky
- Registre A : le nombre d’issues Bug liées
- Registre B : le nombre d’issues Task liées
- Compteur ordinal : l’état d’une unique issue Epic
- Table de dispatch : les règles Jira Automation associées à chaque état d’instruction
- Horloge : les transitions déclenchées par l’automatisation, ou un redéclenchement externe après la limite de chaîne
L’état de l’Epic encode l’instruction courante, et les règles Automation examinent le nombre d’issues liées pour passer à l’état suivant
INC et DEC sont implémentés par la création et la suppression d’issues liées du type concerné, et les branchements conditionnels sont gérés par des règles conditionnelles JQL

Exemples d’exécution et limites

Le programme d’addition est composé comme un programme de Minsky qui diminue A tout en augmentant B
```
1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
```
L’implémentation minimale se compose d’un Epic, de 5 issues liées et d’une règle Automation par état d’instruction
Workflow et règles
- Dans le workflow Jira, créer un état initial BACKLOG, puis TODO, DEV et PROD, en configurant des transitions possibles entre tous les états
- Créer un Epic dans l’état BACKLOG
- La règle TODO implémente DEC A; if A=0 halt, else goto DEV
  - Elle se déclenche lorsque l’état de l’Epic passe à TODO
  - S’il y a au moins un Bug lié, elle supprime un Bug et fait passer l’Epic à DEV
  - S’il n’y a pas de Bug, elle fait passer l’Epic à PROD pour s’arrêter
- La règle DEV implémente INC B; goto TODO
  - Elle se déclenche lorsque l’état de l’Epic passe à DEV
  - Elle crée une nouvelle Task et la lie à l’Epic
  - Elle fait passer l’Epic à TODO
- Les deux règles ont l’option "Allow rule to trigger other rules" activée
Valeurs initiales et résultat
- Initialiser A=2 et B=3 en liant 2 Bug et 3 Task à l’Epic
- En faisant passer l’Epic à TODO, l’exécution en chaîne suit alors le flux suivant
```
(2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
```
- L’exécution a eu lieu sur une instance réelle *.atlassian.net, et à la fin l’Epic atteint PROD avec 0 Bug et 5 Task liées
- Cette exécution correspond au calcul de 2 + 3 = 5 par l’automatisation Jira
Configuration Fibonacci
- Convert Issue Type peut changer instantanément le type d’une issue, par exemple de Bug → Story ou de Story → Task
- CONVERT peut s’exprimer comme DEC + INC, ce qui n’étend pas la puissance de calcul, mais réduit la table de dispatch des boucles de déplacement et facilite la gestion de programmes plus complexes
- Fibonacci s’exprime comme (A, B) → (B, A+B) et se compose de trois registres A=Bug, B=Task, C=Story et de trois états 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
```
- L’état initial est A=1, B=1, C=0, et la suite 1, 1, 2, 3, 5, 8, 13, ... apparaît dans B, c’est-à-dire dans le nombre de Task
- Contrairement à la machine d’addition, la machine de Fibonacci n’a pas d’état d’arrêt et s’exécute jusqu’à atteindre la limite de profondeur de chaîne de 10 sur Jira Cloud
- Une fois cette limite atteinte, un opérateur peut redéclencher l’Epic pour poursuivre, et une simple modification d’état relance l’exécution en chaîne
- Jira Data Center expose automation.rule.execution.timeout et les réglages associés comme propriétés configurables
- En supposant une création d’issues et une exécution de règles infinies, le langage d’automatisation de Jira peut encoder une machine à deux compteurs, et selon le critère usuel voulant que les ordinateurs physiques soient eux aussi finis, les quotas finis de Jira Cloud ne réfutent pas cette construction

1 commentaires

GN⁺ 3 시간 전

Avis sur Hacker News

Jira est tellement complètement affreux qu’il a le potentiel de se transformer en n’importe quelle autre forme d’horreur
- Jira est l’exemple ultime du concept d’aliénation
  Si Marx avait connu Atlassian, le Grundrisse aurait été en fusion
- Le pire, c’est que toutes les entreprises qui fabriquent des produits de gestion du travail finissent par aller dans la direction de Jira
  Il suffit de comparer GitHub Issues en 2014 à ce que c’est devenu aujourd’hui : https://github.com/features/issues
  et ils continuent, encore et encore, à ajouter des fonctionnalités en doublon
Jira est populaire et dispose aussi de bons wrappers d’API pour le langage qu’on préfère
Ce qui est surprenant, c’est que les développeurs d’entreprise avec un esprit hacker n’aient pas automatisé la plupart de ce que Jira leur demande avec des choses comme des scripts en ligne de commande Python
Si je peux le rendre d’un ordre de grandeur plus simple à utiliser que ceux qui imposent Jira, alors le rapport de force s’inverse et Jira devient un outil qu’on pousse pour se protéger
Il m’est arrivé d’utiliser Jira de façon presque malveillante, et c’est excellent pour se défausser des responsabilités
Quand un problème survient, il suffit de dire : « C’était clairement indiqué dans les centaines de mises à jour Jira que j’ai rédigées, vous les lisiez bien, non ? »
Maintenant qu’on a aussi l’IA, il suffit de tout relier avec des scripts custom pour laisser l’IA s’occuper de la corvée Jira
- Pas mal de gens l’ont déjà fait, mais le problème, c’est que chaque instance Jira est une fractale de flocon de neige de propriétés custom, avec des couches successives d’anciennes migrations ratées et de nouvelles stratégies organisationnelles
  Souvent, l’API permet de faire des choses que l’UI n’autorise pas, et comme tout le monde raisonne à partir de l’UI, on tombe dans des coins bizarrement cassés
  Par exemple, on peut ne pas remarquer que custom_field_5537 doit être apparié avec custom_field_442 pour apparaître dans le dashboard de quelqu’un d’autre
  Ou encore custom_field_10995 prétend être un champ entier et est même renvoyé comme entier en XML, mais au moment de créer une tâche il faut utiliser une chaîne de constante magique non documentée, alors que pour les mises à jour ce n’est plus nécessaire
  L’interface web ne fait pas ça : dans le HTML et les requêtes, on trouve simplement un entier, et seulement 80 % de la chaîne correspond au texte affiché dans la liste déroulante
  L’automatisation Jira a été la pire expérience de programmation que j’aie jamais vécue
  Il existe sûrement des configurations plus simples, et ça peut même être assez facile, mais malgré tout c’est trop extrême
  Tristement, l’effort en vaut quand même totalement la peine. Je recommande vivement
- Dans un ancien poste, j’ai créé plusieurs outils qui faisaient gagner du temps via l’API, et c’étaient tous de petits scripts shell
  On avait ajouté à chaque ticket un champ texte custom avec une description lisible par un humain, et quand une release était déployée, le script de déploiement remplissait automatiquement l’horodatage
  On publiait un ticket par unité de travail, et on en traitait plusieurs par jour
  Combiné à des filtres custom, Jira fournissait ainsi un changelog lisible par des humains pour chaque board et pour l’ensemble de l’entreprise, et ces messages étaient envoyés sur Slack aux équipes métier pour que tout le monde sache ce qui était déployé
  C’était aussi un journal d’audit des releases consultable, relié aux changements de code
  Le processus de déploiement faisait aussi avancer le statut des tickets Jira, si bien que le développeur n’avait qu’à merger le ticket dans main pour qu’il soit déployé et marqué comme terminé dans Jira
  Il y avait aussi beaucoup de petits scripts qui créaient automatiquement des tickets pour les tâches récurrentes
  Pendant des années, ça a été très robuste, et il y a de fortes chances que ça tourne encore aujourd’hui
  La convention de nommage des champs custom n’était pas fameuse, mais si l’équipe contrôle la configuration Jira, il n’est pas difficile de maintenir la même discipline partout
  Au départ je n’aimais pas Jira, et il y a longtemps il avait beaucoup de problèmes, mais aujourd’hui, si la configuration est bien faite, ce n’est pas si mauvais
  Je ne le choisirais pas pour mon entreprise, mais pour l’avoir utilisé comme développeur, admin, utilisateur final et développeur d’outils internes, une fois configuré et lancé, en général il ne gêne pas trop
- « Tout relier avec des scripts custom pour laisser l’IA s’occuper de la corvée Jira », ça donne l’impression que l’obésité de Jira n’est déjà pas suffisante
  Si on ajoute encore plus de texte, Jira va somehow tout exécuter automatiquement sur toute cette masse de texte, donc ça va juste devenir plus lent
  Si votre entreprise a besoin de chauffage, utilisez Jira
- On a migré vers JetBrains YouTrack il y a très longtemps, et on fait ce genre de choses avec son API
  C’est assez flexible, et l’IA a encore élargi les possibilités
- Toute notre entreprise tourne en fait pratiquement sur Jira
  La plupart des processus dépendent de Jira, et certaines transitions déclenchent des webhooks pour les automatisations
  Une des toutes premières choses que j’ai faites dès que j’ai obtenu un accès à l’IA, ça a été de créer Jira MCP
  Maintenant, j’essaie de ne presque plus toucher Jira directement, et je demande à Claude de créer des tickets Jira, rédiger des commentaires, créer des sous-tâches, lier des tickets, etc.
  Avant, je redoutais chaque fois qu’il fallait étudier une implémentation et la découper en tâches
  Parce que plus je détaillais, plus il fallait créer de tickets Jira pour porter chaque tâche
  Maintenant, il suffit de tout organiser dans un fichier et de laisser un grand modèle de langage s’occuper de la corvée Jira
Quand je suis retourné dans mon ancien job, ils utilisaient toujours JIRA
En entretien, j’ai évidemment répondu : « Ah JIRA, vous utilisez encore ça ? Oui, je peux m’en servir. »
En pratique, oui, je peux l’utiliser, mais j’ai été vraiment choqué en voyant la version récente de JIRA
Il y a un millier de petites irritations, et l’une des pires, c’est que quand on essaie de sélectionner du texte par double-clic, le champ passe soudainement en mode édition
Dans mon souvenir, c’était JIRA Server 4.0, et on peut s’en remémorer ici : https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
En zoomant suffisamment, chaque ticket affichait le titre, le type, la version corrigée, la version affectée, etc., avec les commentaires juste à la suite. C’était très simple
- Le problème du double-clic qui passe en mode édition est tout à fait réel
  C’est incroyablement agaçant. Même la manipulation de texte la plus basique est ratée
  Mais un chef de projet m’a dit qu’il aimait ça
  Parce qu’il n’utilise pas le double-clic glissé pour sélectionner un mot entier
  Comme toujours, les utilisateurs avancés sont tirés vers le bas pour accommoder des gens qui savent à peine utiliser un ordinateur
- La réaction « JIRA ? Vous utilisez encore ça ? » me paraît étrange
  Je me demande si j’ai raté quelque chose, ou si je suis tombé dans une faille temporelle
  Je ne comprends pas pourquoi on parle de Jira comme de Visicalc
  Je ne travaille plus dans une boîte IT, donc j’ai peut-être raté un grand bouleversement ces deux dernières années
- On peut trouver une corrélation entre le cours de l’action et l’époque où le produit conservait encore une bonne image auprès des utilisateurs
  Quand on est passé de la 4.x à la 6.x, les petites irritations sont arrivées aussi, comme avec les boîtes brinquebalantes d’OFBiz et d’autres produits totalement différents dont seule la façade correspondait
  Ces ingénieurs sont partis depuis longtemps, et les 280 dollars par action sont partis avec eux
- Maintenant que je n’ai plus besoin d’utiliser Jira ou un outil similaire dans mon vrai travail, je suis sincèrement curieux : existe-t-il un consensus sur de meilleures alternatives, non seulement du point de vue des développeurs, mais de toute l’équipe projet ?
- Même cette version de JIRA pouvait facilement devenir affreuse avec une mauvaise configuration
  Le problème fondamental de JIRA, c’est que le pouvoir de le configurer correctement est toujours entre les mains d’une petite minorité, et que ces gens sont soit trop occupés, soit pas motivés, soit n’en ont rien à faire parce qu’ils ne l’utilisent pas tous les jours
  Bien sûr, ce n’est pas le seul problème
  C’est incroyablement lent, et il y a aussi des limitations absurdes, comme le fait qu’un ticket ne puisse pas être le parent d’un autre ticket
JIRA est beaucoup trop lent, et les administrateurs donnaient toujours l’impression de ne pas savoir le configurer correctement
Rien que l’avoir utilisé m’a laissé un traumatisme
- On peut dire que ce n’est pas la faute de l’outil
  C’est juste qu’il n’existe pas une seule personne sur cette planète capable de le configurer correctement
  On ne peut pas vraiment tenir un outil responsable de l’incompétence humaine
  La question de savoir pour qui il a été conçu est tout autre, et ce n’est pas le sujet ici
- Ce qui coince toujours, c’est la lenteur
  Au fond, un système de tickets n’est rien de plus qu’une base de données contenant des tickets, leurs relations et leurs états
  Bien sûr, si on ajoute beaucoup de tickets liés, de champs personnalisés et de plugins, la complexité peut exploser
  Malgré tout, je ne comprends pas comment un outil qui manipule essentiellement des données textuelles simples et des pièces jointes peut être aussi insupportablement lent
Enfin, on peut jouer à Doom dans Jira
- Oui. Quake 3 Arena Multiplayer aussi
https://mattrickard.com/accidentally-turing-complete
Cela explique donc pourquoi on ne peut pas déterminer si une tâche Jira va s’arrêter ou non
- Donc ça entre bien dans la catégorie « on peut jouer à Doom dans Jira » ?
  Jira fournit-il aussi le fusil à pompe pour tuer les démons qu’il engendre ?
Essaie plutôt Azure Boards, et tu finiras par aimer JIRA
Parce qu’il n’existe aucun logiciel que Microsoft ne puisse rendre pire
- J’ai toujours détesté Gmail, et je le déteste encore, mais j’ai changé d’avis après avoir changé de boulot l’an dernier et découvert que ma nouvelle boîte utilisait Outlook
  J’ai du mal à trouver des mots pour exprimer correctement mon mépris pour Outlook, et dire que je le « déteste » est à peine un début
  Il peine même à accomplir la tâche la plus élémentaire : recevoir et envoyer des e-mails
  Je reçois une notification sur mon téléphone, j’ouvre l’appli, et il n’y a rien ; je tire vers le bas pour rafraîchir, et il ne se passe toujours rien
  En général, le message n’apparaît qu’au bout de 1 à 15 minutes
  Tout ce qu’on fait dans Outlook est atrocement laborieux
  J’utilisais déjà Outlook à l’époque d’Office 2003, et je n’ai aucun souvenir que ce soit aussi mauvais. Je ne sais pas comment ils ont pu régresser à ce point
  Et je ne veux même pas commencer à parler de Teams. Je ne vois même pas quel problème ce programme est censé résoudre
  Les fichiers partagés sont dans OneDrive, mais aussi dans Teams, et pour une raison quelconque, aussi dans Outlook
  J’ai dû transférer vers OneDrive/Teams/Outlook environ 30 Go de fichiers de sauvegarde de mon ordinateur, des images CloneZilla, et cela a pris une éternité, pendant que le ventilateur de mon portable Ryzen 6 cœurs sous Win11 hurlait sans interruption
  Comment ? Pourquoi ?
Tous les moteurs de workflow et d’orchestration sont turing-complets
Puisque leur objectif même est d’automatiser des flux d’exécution
- Combien d’entre eux peuvent tourner à l’infini ?
  Ou être relancés manuellement pour reprendre là où ils s’étaient arrêtés ?
- Je ne pense pas
  D’abord, JIRA n’est pas un moteur d’orchestration
  Ensuite, ce qu’un workflow doit faire, c’est associer des états à des informations externes et permettre de les manipuler facilement
  Pour être turing-complet, il faut des déclencheurs et des règles, un compteur infini ou quelque chose du genre, deux piles, une bande bidirectionnelle, etc.
  Prouve-moi que j’ai tort
J’aime bien l’automatisation de Jira
Quand j’arrive dans une nouvelle équipe qui utilise Jira, je mets en place des automatisations pour additionner automatiquement les story points des sous-tâches afin de remplir les story points de la tâche parente, ou pour renvoyer automatiquement un ticket dans le backlog s’il lui manque des attributs suffisamment affinés
Par exemple, quand il manque un responsable, des story points, une priorité ou une description
Après un seul sprint, le board de l’équipe est déjà bien plus propre
Je ne sais pas pourquoi ce n’est pas le comportement par défaut, mais c’est facile à corriger avec l’automatisation
- Pourquoi faut-il assigner un responsable pour considérer qu’un ticket est suffisamment affiné ?
  Le responsable devrait être attribué à la personne qui prend le sujet, ça ne devrait pas faire partie de l’étape d’affinage

Jira est Turing-complet

Machine de Minsky construite avec Jira Automation

Exemples d’exécution et limites

Workflow et règles

Valeurs initiales et résultat

Configuration Fibonacci

À lire aussi

1 commentaires

Avis sur Hacker News