2 августа 2023

Опыт миграции решений 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 предлагает заказчикам и интеграторам, задействованным в подобных проектах, наработанные методологию и инструментарий в качестве универсального типового решения, позволяющего обойти большинство сложностей в процессе миграции и обеспечить грамотный перенос всех исторических данных.

Автор: Вла­димир Та­ран­чен­ко, ру­ково­дитель прак­ти­ки BPM iFellow
Источник: Comnews

Команда iTrend начала работу с Институтом iSpring

19 апреля 2024

Институт iSpring — частный ИТ-вуз нового поколения. Он был основан в 2021 году в Йошкар-Оле российским предпринимателем и основателем международной ИТ-компании iSpring Юрием Усковым.

 

Вебинар iTrend «Работодатель-as-a-Service: новая реальность привлечения ИТ-специалистов»

19 апреля 2024

23 апреля в 15:00 пройдет открытый вебинар «Работодатель-as-a-Service: Новая реальность привлечения ИТ-специалистов». Организаторы — коммуникационное агентство iTrend, ассоциация РУССОФТ и консалтинговая группа BITOBE.

 

iTrend: освоить маркировку интернет-рекламы можно только на собственном опыте

25 марта 2024

В феврале 2024 года в Москве прошла Конференция «Digital-коммуникации России». Организатор мероприятия – Ассоциация директоров по коммуникациям и корпоративным медиа России (АКМР). Эксперты конференции обсудили острые вопросы рынка digital, в том числе маркировку интернет-рекламы. Об опыте коммуникационного агентства в рамках перехода на работу по новым правилам рассказала Екатерина Саранцева, директор по развитию iTrend.

 

Медиалогия: iTrend – в ТОП-4 коммуникационных агентств по медиаиндексу за январь 2024 года

20 марта 2024

Коммуникационное агентство iTrend вошло в пятерку агентств, получивших наиболее высокий медиаиндекс по данным рейтинга «Медиалогии» за январь 2024 года. Компания заняла четвёртую строчку ранкинга, набрав 433,2 пункта МИ. Медиаактивность участников рынка оценивалась на основе анализа базы российских СМИ, включающей в себя более 88 тыс. источников — ТВ, радио, газеты, журналы, информационные агентства и Интернет-СМИ.

 

iTrend: интерес деловых СМИ к ИТ вырос в 6 раз за последние пять лет

20 марта 2024

Эксперты коммуникационного агентства iTrend провели исследование, в рамках которого проанализировали, как менялся медиаландшафт в ИТ-индустрии в последние пять лет. В компании сравнили количество упоминаний крупнейших российских разработчиков и системных интеграторов в деловых СМИ и пришли к выводу, что об ИТ-компаниях стали писать в 6 раз чаще.

 
Все новости iTrend