Jira é Turing-completa

 (seriot.ch)
2 pontos por GN⁺ 3 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Jira Automation pode expressar uma máquina de Minsky com dois contadores infinitos e estados de instrução finitos, mostrando a completude de Turing do Jira
  • O estado de um Epic funciona como contador de programa, e as quantidades de Bugs e Tasks vinculados viram os dois registradores, enquanto as regras de Automation formam a tabela de despacho por instrução
  • INC e DEC são implementados com criação e exclusão de issues vinculadas, e o desvio condicional é decidido por regras condicionais JQL que verificam a quantidade de issues vinculadas
  • O exemplo de adição, com A=2 e B=3, reduz Bugs e aumenta Tasks, chegando a 5 Tasks e ao estado de parada em uma execução real em *.atlassian.net
  • O exemplo de Fibonacci reduz os loops usando conversão de tipo de issue e, ao atingir o limite de profundidade de cadeia 10 do Jira Cloud, pode continuar com um novo disparo manual

Máquina de Minsky feita com automação do Jira

  • Jira Automation consegue expressar uma máquina registradora de Minsky com dois contadores infinitos e um número finito de estados de instrução, o que permite uma redução que demonstra a completude de Turing do Jira
  • O modelo provado por Minsky em 1967 é composto apenas por INC r; goto S e if r == 0 goto S else (DEC r; goto S')
  • Os componentes do Jira correspondem a cada elemento da máquina de Minsky
    • Registrador A: quantidade de issues Bug vinculadas
    • Registrador B: quantidade de issues Task vinculadas
    • Contador de programa: estado de uma única issue Epic
    • Tabela de despacho: regras do Jira Automation para cada estado de instrução
    • Clock: transições acionadas pela automação ou um novo disparo externo após o limite da cadeia
  • O estado do Epic codifica a instrução atual, e as regras de Automation verificam a quantidade de issues vinculadas para fazer a transição ao próximo estado
  • INC e DEC são implementados criando e excluindo issues vinculadas do tipo correspondente, e o desvio condicional é tratado com regras condicionais JQL

Exemplos de execução e limitações

  • O programa de adição é composto como um programa de Minsky que reduz A enquanto aumenta B 
    1. if A == 0 goto 3 else (DEC A; goto 2)
2. INC B; goto 1
3. HALT
  • A implementação mínima é composta por um Epic, 5 issues vinculadas e uma regra de Automation para cada estado de instrução

  • Workflow e regras

    • No Jira Workflow, crie o estado inicial BACKLOG e depois TODO, DEV e PROD, configurando todos os estados para que possam transitar entre si
    • Crie um Epic no estado BACKLOG
    • A regra TODO implementa DEC A; if A=0 halt, else goto DEV
      • É disparada quando o estado do Epic muda para TODO
      • Se houver pelo menos um Bug vinculado, exclui um Bug e faz a transição do Epic para DEV
      • Se não houver Bugs, faz a transição do Epic para PROD e para
    • A regra DEV implementa INC B; goto TODO
      • É disparada quando o estado do Epic muda para DEV
      • Cria uma nova Task e a vincula ao Epic
      • Faz a transição do Epic para TODO
    • Em ambas as regras, "Allow rule to trigger other rules" está ativado

  • Valores iniciais e resultado

    • Vincule 2 Bugs e 3 Tasks ao Epic para inicializar A=2, B=3
    • Ao fazer a transição do Epic para TODO, a seguinte cadeia é executada 
      (2,3) TODO →
(1,3) DEV  →
(1,4) TODO →
(0,4) DEV  →
(0,5) TODO →
(0,5) PROD
    • Foi executado em uma instância real *.atlassian.net, e ao final o Epic chega a PROD, com 0 Bugs e 5 Tasks vinculadas
    • Essa execução corresponde ao cálculo de 2 + 3 = 5 pela automação do Jira

  • Configuração de Fibonacci

    • Convert Issue Type pode mudar imediatamente o tipo de uma issue, como Bug → Story ou Story → Task
    • CONVERT pode ser expresso como DEC + INC, então não amplia o poder computacional, mas reduz a tabela de despacho dos loops de movimentação, facilitando lidar com programas mais complexos
    • Fibonacci é expresso como (A, B) → (B, A+B), usando três registradores A=Bug, B=Task, C=Story e três estados 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
    • O estado inicial é A=1, B=1, C=0, e a sequência 1, 1, 2, 3, 5, 8, 13, ... aparece em B, que é a quantidade de Tasks
    • Diferentemente da máquina de adição, a máquina de Fibonacci não tem estado de parada e roda até atingir o limite de profundidade de cadeia 10 do Jira Cloud
    • Ao atingir esse limite, o operador pode disparar o Epic novamente para continuar, e uma única edição de estado reinicia a execução em cadeia
    • O Jira Data Center expõe automation.rule.execution.timeout e configurações relacionadas como propriedades configuráveis
    • Assumindo criação infinita de issues e execução de regras, a linguagem de automação do Jira pode codificar uma máquina de dois contadores, e pelo critério usual de que computadores físicos também são finitos, as cotas finitas do Jira Cloud não refutam essa construção

Leituras relacionadas

1 comentários

 
GN⁺ 3 시간 전
Opiniões no Hacker News

  • O Jira é tão completamente terrível que tem o potencial de se transformar em qualquer outro tipo de terrível

    • O Jira é o exemplo definitivo do conceito de alienação
      Se Marx conhecesse a Atlassian, o Grundrisse teria saído em chamas
    • O pior é que todas as empresas que fazem produtos de gestão de trabalho acabam indo na direção do Jira
      Basta comparar o GitHub Issues de 2014 com o que é hoje: https://github.com/features/issues
      E continuam, continuam adicionando funcionalidades duplicadas

  • O Jira é popular e também tem bons wrappers de API para a linguagem da sua preferência
    É surpreendente que desenvolvedores corporativos com espírito hacker ainda não tenham automatizado a maior parte do que o Jira manda fazer com alguma coisa como scripts de linha de comando em Python
    Se eu conseguir torná-lo mais de uma ordem de grandeza mais fácil de usar do que para as pessoas que impõem o Jira, o jogo vira e o Jira passa a ser uma ferramenta que eu empurro para me proteger
    Às vezes eu usava o Jira de forma quase maliciosa, e ele é excelente para evitar responsabilização
    Quando algo dá errado, dá para dizer: “isso estava claramente escrito em cada uma das centenas de atualizações no Jira que eu fiz, você estava lendo, né?”
    Agora ainda tem IA, então dá para amarrar tudo com scripts customizados e deixar a IA fazer o trabalho braçal do Jira

    • Muita gente já fez isso, mas o problema é que cada instância de Jira é um floco de neve fractal de propriedades customizadas, com migrações antigas fracassadas e novas estratégias organizacionais empilhadas em camadas
      Muitas vezes a API consegue fazer coisas que a UI não permite, e como todo mundo se orienta pela UI, você acaba caindo em cantos estranhamente quebrados
      Por exemplo, você pode não perceber que o custom_field_5537 precisa ser pareado com o custom_field_442 para aparecer no dashboard de outra pessoa
      E o custom_field_10995 diz ser um campo inteiro e também retorna inteiro no XML, mas na criação da tarefa você precisa usar uma string de constante mágica não documentada, enquanto na atualização isso já não é necessário
      A UI web não faz assim e, no HTML e nas requisições, entra só um inteiro, enquanto apenas 80% da string coincide com o texto mostrado no dropdown
      A automação do Jira foi a pior experiência de programação que já tive
      Configurações mais simples com certeza existem e podem até ser bem fáceis, mas ainda assim é absurdo demais
      Tristemente, ainda valeu totalmente o esforço. Recomendo muito
    • Num lugar onde trabalhei antes, criamos várias ferramentas para economizar tempo via API, e todas eram pequenos scripts de shell
      Adicionamos a cada ticket um campo de texto customizado para uma descrição legível por humanos, e quando um release era implantado, o script de deploy preenchia automaticamente um timestamp
      Fazíamos releases de um ticket por unidade de trabalho e processávamos vários tickets por dia
      Combinado com filtros customizados, o Jira fornecia um changelog legível por humanos para cada board e para a empresa inteira, e essas mensagens eram enviadas ao Slack para o lado de negócios, para que todos soubessem o que estava sendo implantado
      Também era um log de auditoria de releases pesquisável, ligado às mudanças de código
      O processo de deploy também fazia a transição do status dos tickets no Jira, então o desenvolvedor só precisava dar merge do ticket na main para ele ser implantado e concluído no Jira
      Também havia muitos pequenos scripts que criavam automaticamente tickets para tarefas recorrentes
      Foi tudo muito robusto por anos e provavelmente ainda está rodando hoje
      As convenções de nomenclatura dos campos customizados não eram grande coisa, mas se a equipe controla a configuração do Jira, não era difícil manter o mesmo padrão para todos
      No começo eu não gostava do Jira e, há muito tempo, ele tinha vários problemas, mas hoje em dia, se você configurar direito, ele não é tão ruim assim
      Eu não escolheria para a minha empresa, mas tendo usado como desenvolvedor, gestor, usuário final e desenvolvedor de ferramentas internas, quando ele está configurado e começa a funcionar, em geral não atrapalha muito
    • “Amarrar tudo com scripts customizados e deixar a IA fazer o trabalho braçal do Jira” parece como se a obesidade do Jira ainda não fosse suficiente
      Se você adicionar mais texto, o Jira de algum modo vai continuar executando tudo automaticamente em cima de todo esse texto, então vai ficar ainda mais lento
      Se a empresa precisar de aquecimento, é só usar o Jira
    • Migramos para o JetBrains YouTrack há muito tempo, e fazemos esse tipo de coisa com a API dele
      É bastante flexível e, graças à IA, abriu ainda mais possibilidades
    • A empresa inteira praticamente gira em torno do Jira
      A maioria dos processos depende do Jira, e certas transições disparam webhooks para automação
      Assim que consegui acesso a IA, uma das primeiras coisas que fiz foi criar um Jira MCP
      Agora eu quase não tento mais mexer no Jira diretamente, e peço ao Claude para criar issues no Jira, escrever comentários, criar subtarefas, vincular issues etc.
      Antes eu ficava com medo sempre que precisava investigar como implementar algo e quebrar isso em tarefas
      Porque quanto mais detalhadamente eu dividisse, mais issues no Jira eu teria que criar para acomodar cada tarefa
      Agora é só organizar tudo num arquivo e deixar o modelo de linguagem grande cuidar do trabalho braçal do Jira

  • Voltei para um lugar onde trabalhei antes e eles ainda estavam usando JIRA
    Na entrevista, obviamente eu disse: “ah, JIRA? vocês ainda usam isso? Consigo usar, sim”
    Na prática eu consigo usar, mas fiquei realmente chocado ao ver o JIRA mais recente
    Tem tipo mil pequenos incômodos, e um dos piores é que, quando você tenta selecionar texto com duplo clique, o campo de repente entra em modo de edição
    O que eu lembrava era o JIRA Server 4.0, e dá para relembrar aqui: https://www.jirastrategy.com/wp-content/uploads/2020/04/depl...
    Se ampliar o suficiente, cada issue tinha título, tipo, versão corrigida, versão afetada etc., e a estrutura levava direto aos comentários. Era muito simples

    • Essa questão de o duplo clique entrar em modo de edição é totalmente real
      Irrita demais. Erra até no básico da manipulação de texto
      Mas um gerente de projeto me disse que gosta disso
      Porque não usa duplo clique e arrastar para selecionar uma palavra inteira
      Como sempre, usuários mais habilidosos acabam sendo nivelados por baixo por causa da conveniência de gente que mal sabe usar computador
    • Essa reação de “JIRA? vocês ainda usam isso?” soa estranha
      Fico pensando se perdi alguma coisa, se caí num buraco no tempo
      Não entendo por que falam do Jira como se fosse Visicalc
      Hoje não trabalho numa empresa de TI, então talvez eu tenha perdido alguma grande mudança nos últimos dois anos
    • Dá para encontrar uma correlação entre o preço das ações e a percepção positiva dos usuários durante o período em que isso se sustentou no produto
      Na transição do 4.x para o 6.x vieram também esses pequenos incômodos, como nas caixas cambaleantes do OFBiz e em produtos completamente diferentes com só a aparência combinando
      Aqueles engenheiros foram embora faz tempo, e levaram junto os US$ 280 por ação
    • Agora que no meu trabalho principal não preciso mais usar Jira nem ferramentas parecidas, fiquei realmente curioso: existe algum consenso sobre alternativas melhores, não só do ponto de vista dos desenvolvedores, mas da equipe inteira do projeto?
    • Até aquela versão do JIRA podia ficar facilmente horrível se fosse mal configurada
      O problema central do JIRA é que a autoridade para configurá-lo direito sempre fica com poucas pessoas, e elas são preguiçosas, ou não têm tempo, ou não usam aquilo todo dia e por isso não se importam
      Claro, esse não é o único problema
      É incrivelmente lento e também tem limitações estranhas, como uma issue não poder ser pai de outra issue

  • O JIRA é lento demais, e os administradores pareciam não saber configurá-lo direito
    Só de ter usado já tenho trauma

    • Dá para dizer que a culpa não é da ferramenta
      É só que não existe uma única pessoa neste planeta capaz de configurá-la corretamente
      Não dá para responsabilizar a ferramenta pela incompetência humana
      Aí a pergunta para quem ela foi feita é um assunto totalmente diferente, e não devemos entrar nisso agora
    • O que sempre pega é a lentidão
      No fim das contas, um sistema de tickets não passa de um banco de dados com tickets, relações entre tickets e estados
      Claro, se houver muitos tickets vinculados, campos personalizados e plugins, a complexidade pode explodir
      Mesmo assim, não entendo como uma coisa que lida com dados de texto simples e anexos consegue ser tão insuportavelmente lenta

  • Finalmente ficou possível jogar Doom no Jira

    • Sim. Quake 3 Arena Multiplayer também

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

  • Então isso explica por que não dá para decidir se alguma tarefa do Jira vai parar ou não

    • Então isso conta como “dá para jogar Doom no Jira”?
      O Jira também fornece uma espingarda pump-action para matar os demônios que surgirem como resultado?

  • Em compensação, experimente usar Azure Boards e você vai passar a amar o JIRA
    Porque não existe software no mundo que a Microsoft não consiga piorar

    • Sempre odiei o Gmail e ainda odeio, mas depois que mudei de emprego no ano passado e a nova empresa usa Outlook, mudei de ideia
      É difícil encontrar palavras que expressem direito meu desprezo pelo Outlook, e dizer que eu “odeio” nem chega a ser um começo
      Ele sofre até para fazer as tarefas mais básicas de receber e enviar e-mails
      Recebo uma notificação de e-mail no celular, abro o app e não tem nada lá; puxo para baixo para atualizar e nada acontece
      Normalmente ele só aparece de 1 a 15 minutos depois
      Tudo o que faço no Outlook é absurdamente trabalhoso
      Eu também usei Outlook lá na época do Office 2003 e não me lembro de ele ser tão ruim assim. Não sei como conseguiram regredir tanto
      Nem quero começar a falar do Teams. Nem sei direito que problema aquele programa está tentando resolver
      Os arquivos compartilhados estão no OneDrive, mas também estão no Teams e, por algum motivo, também no Outlook
      Tive que mover arquivos de backup do computador, umas imagens do CloneZilla totalizando cerca de 30 GB, para OneDrive/Teams/Outlook, e isso levou uma eternidade, enquanto o ventilador do meu notebook Ryzen de 6 núcleos com Win11 ficou girando feito louco o tempo todo
      Como? Por quê?

  • Todos os motores de workflow e orquestração são Turing-completos
    Porque o próprio objetivo deles é automatizar fluxos de execução

    • Quantos deles conseguem rodar infinitamente?
      Ou ser disparados de novo por uma pessoa e continuar de onde pararam?
    • Não acho que seja assim
      Primeiro, JIRA não é orquestração
      Segundo, o que um workflow deve fazer é conectar algum estado com informação externa e permitir manipular isso facilmente
      Para ser Turing-completo, precisa de gatilhos e regras, algo como um contador infinito, duas pilhas, uma fita bidirecional etc.
      Prove que estou errado

  • Gosto da automação do Jira
    Quando entro num time novo que usa Jira, configuro automações para somar automaticamente os story points das subtarefas e preencher os story points da tarefa pai, ou para mover automaticamente tickets de volta para o backlog se faltarem atributos suficientemente refinados
    Por exemplo, quando faltam responsável, story points, prioridade ou descrição
    Depois de apenas uma sprint, o board do time fica muito mais organizado
    Não sei por que isso não é o padrão, mas é fácil corrigir com automação

    • Por que a atribuição de responsável seria necessária para considerar que o ticket foi refinado?
      O responsável deveria ser atribuído a quem pegou aquela tarefa, e não fazer parte da etapa de refinamento