Хабрахабр

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

Всем привет!

Мне пришлось объединять данные из клаудной и серверной Jira и устанавливать объединенные данные обратно на Клауд. Плагины Tempo для Atlassian Jira установлены на большом количестве инстансов Jira как в клауде, так и на серверах. В этой статье я расскажу, как я сделал объединение и миграцию данных Tempo.
Помимо стандартных данных Jira мне еще было необходимо объединить данные из 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 (хотя можно было бы и воспользоваться плагином Project Configurator).

В результате я обнаружил, что на первом инстансе, где уже находились объединенные данные, готовые к переносу на Клауд, отсутствуют следующие данные плагина 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 — для получения данных по командам и создания команд
  • team-membership — для добавления участников команды
  • team_links — для добавления команде линка на проект или доску

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

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

Так как на объединенном инстансе Jira не было никакой информации о значении полей Account и Team, мне нужно было сохранить эту информацию перед миграцией.

Затем все эти ишью со значениями полей я сохранил в файл. Для Jira Cloud я использовал Jira Rest Api для поиска всех ишью, у которых были заполнены поля Account или Team.

Для Jira Server я использовал Jira Java API, чтобы получить значения полей Account и Team.
В результате у меня получилось два файла с информацией об акаунтах и командах для ишью из Jira Cloud и Jira Server.

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

Для обновления полей Account и Team я использовал стандартный Jira Core Rest Api для обновления ишью.

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

Проблем с записями о работе, которые пришли из ишью с Jira Server проблем не было. Все было перенесено без каких-либо правок, а вот с записями о работе из ишью с Jira Cloud возникли проблемы.

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

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

Это было сделано следующим образом:

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

Затем после того, как я установил бэкап с объединенными данным, я удалил все записи о работе, которые были добавлены от стандартного пользователя плагина Tempo и добавил записи из файла, который я получил в пункте 3.

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

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

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

При этом старая связь на самом деле существует в базе данных Tempo. Проблема в том, что если восстановить Jira Cloud из бэкапа, то эта связь уже не видна из Jira Cloud и поэтому приходится заново устанавливать плагин Tempo, и таким образом формируется новая связь между Jira Cloud и Tempo.

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

После того, как я мигрировал записи о работе с Jira Server, у некоторых записей о работе дата списания была на день раньше, чем нужно. 2. Мне пришлось написать программу, чтобы найти все такие записи о работе и изменить дату. Это было связано с временным поясом пользователя и датой списания.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть