Переезд с Jira: аудит плагинов, скриптов и интеграций Ч2

Это вторая статья из серии про выбор системы при миграции с Jira. В первой части мы разобрали технический анализ данных: проекты, пользователей, кастомные поля и воркфлоу. Если не читали — лучше начните с неё, здесь продолжение.

Одна из главных сложностей миграции без потери данных и процессов — это плагины, автоматизации и интеграции. Именно здесь чаще всего прячутся сюрпризы, которые выясняются уже в процессе переезда. Разбираем по порядку.

Плагины: не список, а карта использования

Просто список установленных плагинов не даёт почти ничего. Администраторы часто понятия не имеют, кто и что реально использует. Пользователи, в свою очередь, нередко не знают, что функционал которым они пользуются каждый день — это плагин, а не сама Jira.

Поэтому задача не «посчитать плагины», а понять по каждому: используется или нет, и где именно.

Для Jira Data Center есть два способа это выяснить:

Первый — селекты по базе. Хорошая инструкция есть в документации Atlassian: How to assess app or plugin usage in Jira

Второй — встроенный инструмент для более новых версий: Explore app usage

По каждому плагину нужно выяснить где он используется и что именно через него делается. Смотрим:

• - Кастомные поля плагина — заполненность, количество задач
• - Воркфлоу (пост-функции, валидаторы) — используются ли
• - Дашборды и гаджеты — есть ли на дашбордах
• - Фильтры и доски — используются ли в сохранённых фильтрах
• - Автоматизации — количество правил, где используются данные из плагина
• - Таблицы в БД (данные плагина) — есть ли данные
• - REST API плагина — вызывается ли

На выходе получаем карту «плагин → используется / не используется» с обоснованием. Это нужно, чтобы понять какой функционал критичен, а от чего можно безболезненно отказаться при переезде.

Автоматизации и скрипты: самая трудоёмкая часть

Важно сказать сразу: автоматизации и скрипты не переносятся ни в одну систему автоматически. Их в любом случае придётся переписывать. Поэтому задача этого этапа — не найти способ перенести, а понять что вообще есть, сколько этого и какого характера. Чтобы оценить объём работы и проверить, есть ли в новой системе нужный функционал.

В Jira автоматизации реализуются несколькими способами.

Встроенные автоматизации воркфлоу — о них говорили в первой статье. Валидаторы, кондишены, пост-функции. В большинстве систем-аналогов базовые варианты реализуемы, но проверять нужно по каждому конкретному случаю.

Automation for Jira. У них стандартная структура: триггер, условие, действие. Для оценки объёма смотрим группы триггеров — создание задачи, изменение поля, по расписанию — и группы действий: отправить письмо, создать подзадачу, перевести статус.

ScriptRunner, PowerScript и подобные — здесь возможностей больше всего, и компании этим активно пользуются. Что анализируем:

• - Workflow-скрипты (post-functions, validators, conditions) — смотрим группы триггеров и действий
• - Слушатели (Listeners) — оцениваем, можно ли заменить на webhook или API
• - Плановые задания (Scheduled Jobs) — проверяем, есть ли встроенные аналоги в целевой системе
• - Behaviours (динамические поля) — оцениваем возможность кастомизации интерфейсов в аналогах
• - JQL-функции — ищем аналог в новой системе
• - REST Endpoints — проверяем наличие REST API у аналога (по умолчанию он есть у всех)

Результат этого блока — понимание общего объёма автоматизаций и список функционала, который нужно проверить в целевой системе.

Интеграции: кто стучится в Jira и зачем

Интеграции в Jira работают через REST API. В базе можно просто уточнить, есть ли у системы-аналога API. Но если интеграции принципиальны для работы, лучше разобраться детальнее.

Самый доступный способ — проанализировать Access Log за последние 30 дней и классифицировать все вызовы. Удобнее делать это не по конкретным эндпойнтам, а по бизнес-логике:

• - Чтение задач — получение данных (GET /issue/{key}, POST /search)
• - Создание и обновление — изменение задач (POST /issue, PUT /issue/{key})
• - Комментарии — чтение и добавление (GET /issue/{key}/comment, POST /.../comment)

По каждому типу считаем количество обращений — это покажет что реально критично, а что используется редко.

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

Что получается на выходе

После технического анализа из двух статей у вас будет:

• - Реальные объёмы данных для оценки миграции
• - Карта использования плагинов — что критично, что нет
• - Объём автоматизаций для переписывания и список нужного функционала
• - Понимание интеграций и требования к API новой системы

Это основа для следующего шага — сбора требований от бизнес-пользователей. Техника техникой, но у людей свой взгляд на то, чем они пользуются и что для них важно. Об этом — в следующей статье.

---

Хотите готовый план миграции с Jira? Напишите слово «план» на support@teamlead.ru — пришлём. Не хотите разбираться самостоятельно — мы можем провести анализ и помочь с выбором системы. Напишите нам в телеграм.

Это вторая статья из серии «Переезд с Jira». Чтобы не пропустить следующие — следите за серией в нашем блоге.