Миграция ScriptRunner в Cloud: переносим сценарии, а не файлы Groovy

Начните с назначения каждого расширения

В Jira Data Center накопились listeners, вычисляемые поля, workflow-функции и scheduled jobs. При переезде в Cloud возникает соблазн посчитать скрипты и назначить срок на переписывание каждого файла. Такой подход пропускает главное: часть сценариев больше не нужна, часть выполняется штатной Automation, а некоторые зависят от возможностей локальной платформы. Сначала составьте каталог бизнес-функций и найдите владельца каждой. Скрипт без владельца и понятного результата нельзя автоматически считать обязательной частью целевой системы.

Для каждого сценария запишите триггер, входные данные, изменяемые объекты, внешние системы и критерий успеха. Отметьте прямой доступ к базе, локальные файлы, Java API и зависимости от интерфейса. Эти признаки помогают оценить архитектурное изменение раньше, чем разработчик начнёт переносить синтаксис. Одно короткое расширение с локальным доступом может потребовать больше проектирования, чем длинный независимый расчёт.

Проверяйте паритет по актуальной документации

У ScriptRunner Cloud и Data Center нет полного совпадения функций. Сверяйте таблицу Feature Parity и документацию целевого продукта на момент миграции. Не превращайте старый список ограничений в вечное утверждение: Cloud активно развивается. При этом появление функции с похожим названием ещё не доказывает идентичную поддержку полей, экранов, контекста и способов исполнения. Проверять нужно конкретный сценарий.

Разделите каталог на четыре группы: перенос с небольшой адаптацией, переработка через Cloud API, замена штатной возможностью и отказ по решению владельца. Для неопределённой функции проведите короткий прототип до обещания сроков. Например, UI-логика требует проверки поддерживаемого представления и поля; обработчик события — доступного webhook-контекста; отчёт — актуальности и поиска данных. Результат прототипа должен быть воспроизводимым, а не только демонстрационным.

Выберите целевую архитектуру

Не всякий сценарий должен оставаться скриптом. Простое изменение поля по переходу может быть удобнее поддерживать через Jira Automation. Сложная интеграция с устойчивым прогрессом и строгой защитой от дублей может потребовать отдельного сервиса. Вычисляемое поле, зависящее от дорогого внешнего запроса, иногда лучше заменить фоновой синхронизацией и отметкой свежести. Выбор основан на требованиях к времени, объёму и наблюдаемости.

Для Cloud не предполагайте доступ к локальным объектам Jira и произвольному внутреннему окружению Data Center. Проверьте авторизацию, ограничения API, доступность сети и модель секретов. Источником истины для идентификаторов пользователей и полей должны быть поддерживаемые механизмы целевого сайта. Сопоставление по отображаемому имени недостаточно устойчиво. Отдельно согласуйте, какие сведения допустимо передавать внешней интеграции и где хранится диагностика.

Проверка бизнес-паритета

Для каждого сценария создайте таблицу одинаковых входов и ожидаемых результатов в старой и новой системе. Проверяйте не только счастливый путь, но и пустое значение, отсутствие прав, повтор события, отказ внешней системы и частичное выполнение. Если поведение намеренно изменено, зафиксируйте это как решение владельца процесса. Отличие нельзя скрывать словами «особенность Cloud», когда оно меняет обязательство команды.

Используйте обезличенные тестовые данные и отдельные назначения внешних уведомлений. Параллельный запуск старой и новой интеграций на одних рабочих объектах опасен: обе могут создавать задачи и отправлять письма. Для сравнения применяйте режим чтения и планирования либо разделённые выборки. Сохраняйте идентификаторы исходных и целевых объектов, чтобы можно было проследить результат без ручного поиска по похожим заголовкам.

Переключение и план возврата

Перед миграцией назначьте владельца переключения, окно изменений и критерий остановки. Отключите старые обработчики в согласованный момент, зафиксируйте последний обработанный идентификатор и включите целевую обработку с понятной границы. Для событий, пришедших во время паузы, предусмотрите повторную доставку или контрольную сверку. Не считайте успешный перенос конфигурации доказательством обработки всех событий.

План возврата должен учитывать уже созданные в Cloud объекты и изменённые внешние записи. Простое включение старой системы может повторить действия. Сохраните журнал соответствий и выполняйте компенсацию адресно. После переключения проверяйте свежесть данных, число исключений и ключевые пользовательские переходы. Миграция завершена, когда владельцы подтверждают согласованные бизнес-сценарии, а сопровождение понимает ограничения и способы восстановления каждой новой реализации.

Решение по оставшимся исключениям

Перед завершением миграции составьте явный список сценариев, которые перенесены частично или временно выполняются вручную. Для каждого укажите владельца, рабочую инструкцию, риск, срок пересмотра и критерий готовности замены. Не прячьте исключения в техническом приложении, которое не видят пользователи процесса. Если функция больше не нужна, получите подтверждение владельца и уберите зависимые инструкции. Такой список позволяет запустить Cloud с понятными границами и избежать ситуации, когда после переключения обнаруживается забытый ежемесячный job, от которого зависел важный отчёт или согласование релиза.