Как я объединял данные плагина Tempo для Jira Server и Jira Cloud и мигрировал их обратно в Jira Cloud

Всем привет!
Плагины Tempo для Atlassian Jira установлены на большом количестве инстансов Jira как в клауде, так и на серверах. Мне пришлось объединять данные из клаудной и серверной Jira и устанавливать объединенные данные обратно на Клауд. Помимо стандартных данных Jira мне еще было необходимо объединить данные из Tempo плагина. В этой статье я расскажу, как я сделал объединение и миграцию данных Tempo.

Tempo данные, которые я мигрировал:

• Tempo Accounts (акаунты)
• Tempo Teams (команды)
• Значения полей Account и Team для всех ишью в Jira
• Worklogs (записи о работе)

Процесс объединения и миграции:

Я поднял две Jira со следующей конфигурацией: Jira Software 7.11.2 и Jira Service Desk 3.14.2. Затем я снял бэкап с Jira Cloud и установил его на первый инстанс, затем я снял бэкап с Jira Server и установил его на второй инстанс. После этого я перенес данные со второго инстанса на первый с помощью плагина Configuration Manager ^[1] (хотя можно было бы и воспользоваться плагином Project Configurator ^[2]).
В результате я обнаружил, что на первом инстансе, где уже находились объединенные данные, готовые к переносу на Клауд, отсутствуют следующие данные плагина Tempo:

• данные о Tempo акаунтах
• данные о Tempo командах
• значения в ишью для полей Account и Team
• авторы записей о работе в ишью, которые были загружены из Jira Cloud

Нужно было заполнить эти данные при миграции.

Как я мигрировал данные плагина Tempo

Акаунты

С акаунтами мне повезло. В плагине Tempo есть встроенная функциональность по экспорту и импорту акаунтов.
Все, что мне нужно было сделать, это перед установкой объединенных данных в Jira Cloud экспортировать акаунты из Jira Cloud и Jira Server в файлы, а затем, после загрузки объединенных данных в Jira Cloud, импортировать эти файлы в Клауд.
Была только одна проблема, что некоторые ключи акаунтов в Jira Cloud и Jira Server совпадали, поэтому мне нужно было в одном их файлов эти ключи поменять. Иначе при импорте данных акаунта с одинаковыми ключами акаунты будут либо обновлены, либо заархивированы, а мне ни одни из этих вариантов не подходил.

Команды

С командами было сложнее. Никакой встроенной функциональности по переносу команд нет. Поэтому пришлось использовать Tempo Rest Api для получения данных по командам, а затем создавать эти команды в Jira Cloud.
Я использовал следующие Rest вызовы:

• teams ^[3] — для получения данных по командам и создания команд
• team-membership ^[4] — для добавления участников команды
• team_links ^[5] — для добавления команде линка на проект или доску

Я также хотел использовать Tempo Rest Api для установки разрешений команды, но обнаружил баг в этом Api.

Установка правильных значений в поля Account и Team для всех ишью

Так как на объединенном инстансе Jira не было никакой информации о значении полей Account и Team, мне нужно было сохранить эту информацию перед миграцией.
Для Jira Cloud я использовал Jira Rest Api для поиска ^[6] всех ишью, у которых были заполнены поля Account или Team. Затем все эти ишью со значениями полей я сохранил в файл.
Для Jira Server я использовал Jira Java API, чтобы получить значения полей Account и Team.
В результате у меня получилось два файла с информацией об акаунтах и командах для ишью из Jira Cloud и Jira Server.
Проблема была в том, что после того, как я мигрировал объединенные данные в Jira Cloud и создал акаунты и команды, ид команд и акаунтов стали не совпадать со старыми ид, поэтому при установке правильных значений команд и акаунтов для ишью, мне необходимо было перемэпить старые ид в новые.
Для обновления полей Account и Team я использовал стандартный Jira Core Rest Api для обновления ишью ^[7].

Записи о работе

Проблем с записями о работе, которые пришли из ишью с Jira Server проблем не было. Все было перенесено без каких-либо правок, а вот с записями о работе из ишью с Jira Cloud возникли проблемы.
Связано это с тем, что когда добавляется запись о работе в Jira Cloud с помощью плагина Tempo, эта запись добавляется от пользователя плагина Tempo, а не от пользователя, который делает эту запись. Поэтому для того, чтобы получить правильного пользователя необходимо получать этого пользователя из базы данных плагина Tempo.
По этой причине пришлось получить правильных пользователей записей о работе с Jira Cloud перед тем, как делать миграцию.
Это было сделано следующим образом:

1. Я нашел все ишью в Jira Cloud, где пользователь записи о работе был пользователь плагина Tempo. Сделал я это с помощью стандартного Jira Core Rest вызова ^[8].
2. Затем я получил все Jira ид записей о работе из полученных ишью в пункте 1 с помощью вот этого Rest вызова ^[9].
3. Затем я получил данные из плагина Tempo для всех записей о работе, полученных в пункте 2 и сохранил в файл. Данные я получал с помощью Tempo Rest Api ^[10].

Затем после того, как я установил бэкап с объединенными данным, я удалил все записи о работе, которые были добавлены от стандартного пользователя плагина Tempo и добавил записи из файла, который я получил в пункте 3.
Так же лучше поставить установку поля Remaining Estimate при добавлении записи о работе в опционально. В этом случае не нужно будет каждый раз получать текущее значение поля Remaining Estimate для ишью при добавлении записи о работе.

Неожиданные проблемы

1. Когда устанавливаешь плагин Tempo Timesheets в Jira Cloud, то между Jira Cloud и базой данных Tempo создается связь, которая нужна для того, чтобы при получении данных из плагина Tempo доставались бы именно данные для Вашего инстанса Jira.
Проблема в том, что если восстановить Jira Cloud из бэкапа, то эта связь уже не видна из Jira Cloud и поэтому приходится заново устанавливать плагин Tempo, и таким образом формируется новая связь между Jira Cloud и Tempo. При этом старая связь на самом деле существует в базе данных Tempo.
В результате, когда начинаешь работать с ишью, то данные подтягиваются через старую и новую связь, причем старая связь первична (т.е. если в старой БД Tempo существует команда с таким же ид как и в новой, то название этой команды подтянется из старой БД Tempo). А вот если войти в Администрирование команд и акаунтов через пользовательский интерфейс администратора, то мы увидим корректные данные из последней связи. И если мы создадим кастомный Tempo Report, то мы тоже увидим корректные данные. Поэтому старую связь нужно удалять, и удалить ее можно только обратившись в поддержку Tempo. Правда поддержка Tempo отработала очень оперативно за что я ей благодарен.
2. После того, как я мигрировал записи о работе с Jira Server, у некоторых записей о работе дата списания была на день раньше, чем нужно. Это было связано с временным поясом пользователя и датой списания. Мне пришлось написать программу, чтобы найти все такие записи о работе и изменить дату.

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

Автор: Алексей Матвеев

Источник ^[11]