Опыт миграции решений Atlassian: проблемы и пути решения

Предпосылки миграции решений Atlassian

В 2022 году компания Atlassian, разработчик популярных во всем мире систем для совместной проектной работы Jira и Confluence, приостановил деятельность в России. Новые лицензии Atlassian в стране сегодня официально купить невозможно, однако продукты вендора до сих пор востребованы — в частности, компаниями, которые ранее приобрели подписку на несколько лет вперед.

Вместе с тем владение облачными версиями (Cloud) продуктов Atlassian сегодня связано для российских компаний с большими рисками. Это и стало главной предпосылкой для проекта крупного ритейлера по миграции Jira и Confluence с версии Cloud на DataCenter, то есть в собственный ИТ-ландшафт.

Дополнительные причины — недостаточный уровень доступности исходной системы в облаке, сложность подключения корпоративного хранилища данных (КХД), недостаточная для реализации новых функциональных требований заказчика степень кастомизации версии Cloud.

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

Нюансы стандартного механизма миграции

Компания Atlassian в документации к своим продуктам описывает последовательность миграции Jira с версии Cloud на DataCenter и обратно. В качестве сложностей вендор указывает только на необходимость учета в процессе переноса установленных плагинов и написанных скриптов, если они есть в исходной системе.

Однако на практике команда iFellow столкнулась с другой неочевидной задачей. Дело в том, что в версии Cloud проекты Jira подразделяются на два направления по типу администрирования: Team Managed и Company Managed. При этом Atlassian DataCenter не работает с бэкапом Cloud, который содержит хотя бы один Team Managed проект. В Team Managed проектах все сущности, такие, как типы задач, пользовательские поля, бизнес-процессы, экраны – независимы от других проектов, существуют децентрализовано и используются только для конкретного проекта. Фактически это маленькая система в системе. У Company Managed проектов все реализовано, как в DataCenter: сущности создаются централизованно администраторами Jira.

Решение этой задачи может быть только одно — трансформировать проекты внутри версии Cloud из Team Managed в Company Managed. При этом функциональности в самой Cloud для перевода из одного типа в другой попросту нет.

Для перевода каждого проекта из Team Managed в Company Managed необходимо сначала создать и подготовить по аналогии новый Company Managed проект, то есть централизованно создать все необходимые типы задач, перерисовать бизнес-процессы, создать пользовательские поля с нужными типами и названиями, подготовить экраны. После подготовки необходимо перенести задачи из одного проекта в другой для сохранения истории работы над задачей, комментариев и т. д.

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

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

Файл бэкапа Cloud представляет собой архив с xml-файлами и файлами вложений. При большом объеме вложений рекомендуется извлечь их из файла бэкапа и просто скопировать на сервер. Создание бэкапа в Cloud возможно раз в 48 часов — это важно учитывать при создании плана миграции.

Поддержка версии DataCenter: решение проблем, возникших при миграции

После окончания импорта и запуска тестовой Jira DataCenter мы столкнулись с первой проблемой: большая часть пользователей "переехала" с логинами в виде хэш-кода. Такая ситуация случается, если пользователь был "приглашен" в Cloud-версию и проходил авторизацию через личный кабинет Atlassian. Например, пользователь Иванов Иван авторизовывался в Cloud, указывая e-mail ivanov.ivan@company.ru. После миграции его логин имеет вид 5f1598bc9e8ba30016f29d6a, и авторизоваться ему придется именно под ним. Это большая проблема, учитывая то, что в дальнейшем необходима интеграция с LDAP. Если же пользователь был создан вручную внутри Jira Сloud, его логин мигрируется корректно.

Стоит отметить, что при миграции Confluence эта проблема была не так критична, так как таким пользователям в качестве логина присваивалась почта, что в большинстве случаев позволяет выполнить маппинг без больших затрат.

Для правильной синхронизации с LDAP и маппинга мигрированных пользователей необходимо, чтобы логин пользователя из Сloud совпадал с логином из LDAP. Поэтому появляется задача изменения логинов пользователей из Cloud после миграции.

Вторая проблема — ссылки на Confluence в задачах все еще ведут в Confluence Cloud, а не на мигрированный Confluence Data Center. При этом структура ссылок Confluence Cloud разительно отличается от Confluence Data Center. Возникает еще одна задача по корректировке ссылок.

Третья проблема — не создаются задачи/подзадачи, не сохраняется изменение пользовательских полей, вместо привычного списка подзадач у задачи отображается текст ошибки сервера. Здесь загвоздка в базе данных. Формируется некорректный экспорт технических записей в таблицах счетчиков и связей задач. Для решения проблемы мы занимаемся "починкой" базы данных для корректной работы.

Четвертая проблема не так критична, но тоже имеет место: "ломается" левая панель проектов, в которых в Сloud были созданы и прикреплены ссылки. Здесь также необходима манипуляция с базой.

Пятая проблема — так как в Jira Cloud и в Data Center используется разный формат в комментариях к задачам для упоминания пользователей, после миграции вместо упомянутого пользователя в комментарии написано нечто вроде "[~accountid:5f1598bc9e8ba30016f29d6a] — просьба обратить внимание на задачу". Решение — править данные в комментариях для приведения упоминания к формату Data Center.

Миграция Confluence не вызывает таких сложностей: необходимо изменить только ссылки на Jira на новый url. И, так как формат ссылок одинаковый, достаточно сменить base url. Также нужно сменить логины пользователей для дальнейшей интеграции с LDAP. Из неожиданного — мы столкнулись с "битыми" символами внутри xml-файла, но это известная проблема и у вендора есть готовый инструмент.

Универсальная разработка iFellow. Резюме

Для решения всех упомянутых выше проблем специалисты iFellow написали универсальный инструмент, который реализует несколько процессов:

• парсинг XML-файла с бэкапом Jira Cloud для изменения и адаптации ссылок на мигрированный Confluence Data Center;
• замену логинов при помощи файла-маппинга логинов из Сloud и LDAP;
• приведение к правильному формату упоминаний пользователей в комментариях в нужный формат;
• sql-скрипты, которые "чинят" сбитые счетчики в таблицах, исправляют линки для сабтасков.

В рамках пилотного проекта мы убедились в том, что миграция продуктов Atlassian с версии Cloud на DataCenter возможна. Однако в некоторых случаях она подразумевает наличие большого количества доработок и плагинов: как минимум потому, что API версии DataCenter шире, а выбор ее плагинов богаче.

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

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