Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Почему ошибка выглядит правдоподобно
После перевода заявки на релиз в согласованное состояние команда создаёт техническую задачу для эксплуатации. Следом правило добавляет комментарий с инструкцией и выставляет поле команды. Задача действительно создаётся, журнал показывает успешное выполнение, но комментарий и поле оказываются у исходной заявки. Причина в контексте: создание новой задачи само по себе не переключает последующие действия основной ветки на созданный объект. Это особенно неприятно, когда поля существуют в обоих проектах и ошибка не вызывает технического отказа.
Перед настройкой нарисуйте два объекта: заявку бизнеса и техническую задачу. У каждого перечислите разрешённые изменения. Для заявки это ссылка на результат; для технической задачи — исполнитель, описание и инструкции. Такой список позволяет проверить правило по итоговым данным, а не только по зелёному статусу журнала.
Создание и явный переход в нужную ветку
Настройте ограниченный триггер перехода исходной заявки и условия проекта, типа и целевого статуса. Создайте техническую задачу с минимальным набором полей. Затем используйте Related issues branch для All created issues, если требуется обработать все созданные в этом выполнении задачи. Действия добавления комментария и изменения полей разместите внутри этой ветки. Основная ветка продолжает относиться к задаче, запустившей правило; её действия должны быть предназначены именно ей.
Если создаётся несколько задач разных типов, добавьте условия внутри ветки, чтобы инструкция эксплуатации не попала в задачу тестирования. Не рассчитывайте, что последняя визуально расположенная операция создания автоматически задаёт контекст дальнейших действий. Откройте документацию для конкретного варианта ветвления и проверьте, какой набор объектов он возвращает. В названии компонентов полезно явно указывать объект: исходная заявка, созданная задача или связанный инцидент.
Сохраните исходные значения до ветвления
При работе внутри связанной задачи значение issue описывает текущий контекст этой ветки. Если нужен ключ исходной заявки, используйте предназначенный для исходного события контекст triggerIssue и проверьте его через Log action. Например, диагностическое сообщение может показывать одновременно {{issue.key}} и {{triggerIssue.key}}. Это небольшой тест, который сразу выявляет неверное предположение о том, к какой задаче обращается компонент.
Выбирайте минимум данных для переноса. Резюме, ссылка и согласованные параметры релиза обычно достаточны; полный текст описания может содержать внутреннюю переписку или данные клиента. Если значение вычисляется на основе нескольких полей, проверьте его до создания задач. Отдельно обработайте пустую версию, отсутствующую команду и переименованное поле. Автоматическая подстановка пустоты часто технически успешна, но создаёт непригодную для работы задачу.
Не стройте зависимости между параллельными ветками
Ветки, обрабатывающие несколько задач, могут выполняться параллельно. Atlassian прямо предупреждает об отсутствии гарантированного порядка и о независимом выполнении основной ветки. Поэтому схема «первая подзадача записывает итог, следующая читает его» ненадёжна. Не используйте комментарий из одной ветки как сигнал завершения всех остальных. На небольшой тестовой выборке гонка может не проявляться, а при нагрузке результат станет непредсказуемым.
Если требуется общий результат по всем подзадачам, отделите изменение отдельных объектов от последующей проверки состояния. Например, отдельное событие изменения подзадачи запускает проверку актуального состояния родителя. При этом условие должно проверять фактические данные, а не ожидать конкретного порядка событий. Повторный запуск такой проверки должен быть безопасным и не создавать повторные задачи релиза.
Матрица проверки и восстановление
Подготовьте случаи с одной, несколькими и нулём создаваемых задач. Добавьте задачу в другом проекте, где техническому пользователю не хватает одного права, и проверьте частичный результат. Сравните историю каждого объекта: комментарий и поле команды должны находиться только там, где это указано в начальной схеме. Для правила создания обязательно проверьте повторный переход исходной заявки в согласованный статус: нужно либо повторное создание по бизнес-правилу, либо явная защита от дублей.
При ошибке сначала отключите правило, соберите ключи затронутых задач из журнала и сохраните исходные значения полей. Исправляйте только изменения конкретного выполнения. Если человек уже отредактировал задачу после автоматизации, не возвращайте поле вслепую. После восстановления запустите исправленное правило на одной контрольной заявке, проверьте обе стороны связи и лишь затем расширяйте область действия.
Чек-лист проверки результата
На приёмке откройте исходную заявку и все созданные задачи рядом. Сверьте тип, проект, команду, комментарий и ссылку на исходный объект. Для каждого поля заранее укажите, на какой стороне оно должно измениться. Проверьте, что комментарий технической команды не появился в бизнес-заявке и не стал доступен лишним пользователям. Добавьте повторный запуск и случай частичного отказа доступа. Сохраните результаты в карточке изменения правила. Такая проверка ловит ошибки контекста, которые остаются незаметными при просмотре одного журнала с успешным статусом, и делает последующий review существенно точнее.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу