В фольклоре разработчиков встречаются утверждения о том, что Jira (система управления проектами, разработанная Atlassian) полна по Тьюрингу. Однако в таких заявлениях нет конкретики, лишь смутные упоминания фич автоматизации. В этой статье будет приведено доказательство с инструкциями по реализации и трассировкой исполнения.
Составление вычислительной модели
Для машины Минского требуются всего два неограниченных счётчика и конечное множество именованных команд:
INC r; goto SDEC r; if r == 0 goto S else goto S'
Если говорить русским языком:
выполнить инкремент регистра R, затем перейти в некое состояние S
выполнить декремент регистра R, если R == 0, перейти в нулевое состояние S, иначе перейти в ненулевое состояние S'
Программа Минского, складывающая регистр A с регистром B и сохраняющая значение в B, выглядит так:
1. DEC A; if A == 0 goto 3 else goto 2 2. INC B; goto 1 3. HALT
Минский доказал, что эта модель Тьюринг-полная (1967 год). Следовательно, продемонстрировав её на языке автоматизации Jira, мы получим нужное нам доказательство. Вот, как модель связывается с Jira:
Машина Минского | Jira |
|---|---|
Регистр A | Количество связанных задач типа Bug |
Регистр B | Количество связанных задач типа Task |
Счётчик команд | Статус одной Epic-задачи |
Таблица диспетчеризации | Правила автоматизации Jira, по одному на состояние команды |
Часы | Запускаемые автоматизацией переходы или внешние повторные срабатывания прошлых цепочек прав |
В статусе Epic кодируется текущая команда. Правила автоматизации проверяют количество связанных задач и выбирают следующий статус. INC и DEC реализованы как создание и удаление задачи соответствующего типа связанной задачи. Условное ветвление реализовано в виде условного правила JQL.
Реализация сложения
Ниже представлена минимальная работающая реализация на основе одной Epic, пяти связанных задач и одного правила автоматизации на каждое состояние команды (Space Settings > Automation).
1. Создание Workflow
Создаём Jira Workflow со статусами начальных состояний BACKLOG, затем TODO, DEV и PROD. Любое состояние может выполнять переход в любое другое.
Создаём Epic в статусе BACKLOG.
2. Создание правила для TODO
DEC A; if A=0 halt, else goto DEV.
Триггер: статус Epic изменён на
TODO.Если есть хотя бы один связанный Bug: удаление одного Bug, переход Epic в состояние
DEV.Иначе: переход Epic в
PROD(останов).
3. Создание правила для DEV
INC B; goto TODO.
Триггер: статус Epic меняется на
DEV.Создание новой задачи, привязка её к Epic.
Переход Epic в состояние
TODO.
У обоих правил выставлен флаг «Разрешить этому правилу вызывать другие правила».
На скриншоте ниже показаны два правила, связанные с workflow Epic.
4. Инициализация регистров
Привязываем 2 Bug (A=2) и 3 Task (B=3) к Epic.
5. Запуск машины.
Выполняем переход Epic в состояние TODO для запуска каскада. Пять переходов:
(2,3) TODO → (1,3) DEV → (1,4) TODO → (0,4) DEV → (0,5) TODO → (0,5) PROD
Записано на реальном инстансе *.atlassian.net.
Epic оказывается в состоянии PROD с 0 связанных Bug и 5 связанных Task. Так мы выполнили сложение 2 + 3 = 5.
Вычисление чисел Фибоначчи в трёх состояниях
Приведённого выше доказательства достаточно для демонстрации полноты по Тьюрингу. Наряду с этим язык автоматизации Jira может упрощать операции Минского. Convert Issue Type мгновенно меняет тип задачи: Bug → Story, Story → Task и так далее.
CONVERT можно выразить как DEC + INC. Она не повышает вычислительную мощь Jira, но существенно уменьшает таблицу диспетчеризации для цикла копирования, что позволяет реализовывать нетривиальные программы.
Вычисление чисел в Фибоначчи в виде (A, B) → (B, A+B) сводится к трём состояниям с тремя регистрами (A=Bug, B=Task, C=Story); тремя состояниями команд будут TODO, QA (нужно добавить его в workflow) и 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
Начальное состояние имеет вид A=1, B=1, C=0. Последовательность 1, 1, 2, 3, 5, 8, 13, … записывается в B (счётчик Task).
В отличие от машины сложения, у машины Фибоначчи нет состояния останова. Она работает, пока не упрётся в максимальную глубину цепочек прав, равную 10 срабатываниям; после этого оператор заново запускает Epic для продолжения. Для перезапуска каскада достаточно одного изменения статуса.
Доказательство по-прежнему в силе, живой оператор просто передаёт машине следующий такт. В Jira Data Center есть аналогичное свойство automation.rule.execution.timeout и связанные с ним конфигурируемые свойства.
Заключение
Язык автоматизации Jira при условии неограниченного создания задач и исполнения правил способен закодировать машину с двумя счётчиками . Все физические компьютеры конечны, поэтому конечный лимит Jira Cloud не опровергает наши построения. В рамках этого стандартного допущения Jira полна по Тьюрингу.
Поэтому если сложные автоматизации Jira кажутся вам похожими на программы, то это потому, что именно так всё и есть.
