Всем привет!

Плагины 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 (хотя можно было бы и воспользоваться плагином 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 возникли проблемы.

Связано это с тем, что когда добавляется запись о работе в Jira Cloud с помощью плагина Tempo, эта запись добавляется от пользователя плагина 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.

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

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

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

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

Комментарии (5)


  1. gecube
    07.10.2018 23:04

    Я почуствовал себя лохом, т.к. пользуюсь Atlassian и не знаю — что же это за зверь такой — Tempo плагин. А может их и несколько вовсе? А может он настолько крутой, что нужно срочно брать и его докупать!? Не знаю. В общем, без двух предложений про этот плагин статья не имеет никакого смысла :-(


    1. nick7ikin
      08.10.2018 20:12

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


      1. gecube
        08.10.2018 21:40

        Спасибо за комментарий. Просто автор статьи пишет про «плагин Tempo» в единственном числе. Угадать его мысли — невозможно. Поэтому я и попросил сделать краткую заметку про «плагин Tempo» (предполагая, что их несколько разных для разных целей).


  1. GiAS
    08.10.2018 14:31

    Замечательный плагин, вот только он все worklogs делает от имени себя и комментарии к ним заменяет на «time-tracking», а информацию о пользователе/комментарии хранит где-то у себя. Чем ломает работу других плагинов. Не надо так.


    1. aleme Автор
      08.10.2018 14:31

      Да, есть такое поведение на Cloud.