Jira 图灵完整：在 Atlassian Automation 中构建 Minsky 机器

多年来，工程界的民间传说一直暗示 Jira——Atlassian 无处不在的项目跟踪工具——是图灵完整的。虽然许多人曾模糊地指出其自动化功能作为证据，但很少有人提供正式的归约来证明这一点。

最近，Nicolas Seriot 通过演示如何在 Jira 的自动化框架内构建 Minsky 寄存器机器提供了该证明。这一发现将 Jira 从一个简单的票据跟踪器转变为理论计算机，解释了为什么复杂的 Jira 配置常常感觉像编程——因为从形式意义上讲，它们确实是这样。

计算模型：Minsky 机器

为了证明图灵完整性，Seriot 使用了 Minsky 寄存器机器。Minsky 机器是一种只需要两个无界计数器（寄存器）和一组有限的带标签指令的理论计算模型。允许的操作只有：

Increment (INC r; goto S): 增加寄存器 r，然后移动到状态 S。
Decrement/Branch (DEC r; if r == 0 goto S else goto S'): 减少寄存器 r。如果寄存器已经为零，则移动到状态 S；否则，移动到状态 S'。

Marvin Minsky 在 1967 年证明了这个最小模型是图灵完整的。因此，如果这些操作可以映射到 Jira 的功能上，那么 Jira 也是图灵完整的。

Seriot 的归约将 Minsky 机器的理论组件映射到特定的 Jira 实体：

在此模型中，Epic 的状态充当当前指令指针。自动化规则检查链接问题的数量（即寄存器）并确定下一个状态（下一状态）。增量和减量通过创建或删除链接问题来处理，而条件分支则通过带有 JQL 条件的规则实现。

为了演示证明，Seriot 实现了一个简单的加法程序（将寄存器 A 加到寄存器 B）。该设置需要一个具有状态 BACKLOG、TODO、DEV 和 PROD 的 Jira 工作流。

State TODO (DEC A): 如果至少存在一个链接的 Bug，则删除一个 Bug 并将 Epic 转移到 DEV。否则，将 Epic 转移到 PROD（停止）。
State DEV (INC B): 创建一个新的 Task，将其链接到 Epic，并将 Epic 转回到 TODO。

通过将 Epic 初始化为 2 个 Bug（A=2）和 3 个 Task（B=3），并将其转移到 TODO，系统会级联通过规则直到达到 PROD。最终结果是 0 个 Bug 和 5 个 Task，实际上计算 2 + 3 = 5。

虽然加法示例证明了理论，但 Jira 的自动化语言提供了一个 Convert Issue Type 操作，简化了流程。将 Bug 转换为 Story 在功能上等同于先执行 DEC Bug 再执行 INC Story。

使用此快捷方式，Seriot 仅使用三个状态（TODO、QA、DEV）和三个寄存器（Bugs、Tasks、Stories）实现了一个斐波那契序列生成器 (A, B) → (B, A+B)。

一个实际限制是 Jira Cloud 的链深度上限（通常为 10 个触发器），这防止了无限循环。然而，正如 Seriot 所指出的，这是托管环境的物理限制，而不是语言的理论限制。人工操作员可以简单地重新触发 Epic 以提供下一个 “clock tick”，从而保持归约的有效性。

Jira 是图灵完整的这一发现在开发者中引发了广泛讨论。许多人指出，这解释了为什么 Jira 通常感觉就像用汇编语言编程来实现基本目标。

一位评论者 @lmm 开玩笑说，这解释了为什么通常不可能判断给定的 Jira 操作是否会永远停止——这直接指向了停机问题。

"如果你能让 Jira 对自己使用的难度比对推动它的人低一个数量级，那么剧情就会反转，Jira 就会成为你用来保护自己的东西。* — @Buttons840

"实际上，成为图灵完整很容易。对于一个系统来说，既非图灵完整又‘复杂’是一项成就。* — @itemize123

通过将 Minsky 机器归约到 Jira 自动化，我们可以正式得出结论：Jira 是图灵完整的。虽然很少有开发者会实际使用 Jira 编写软件，但该证明凸显了现代企业软件的一个基本真理：当一个工具的自动化能力变得足够复杂时，它不可避免地会成为一种编程语言——通常是一种无意中难以使用的语言。