Всем привет!
Плагины Tempo для Atlassian Jira установлены на большом количестве инстансов Jira как в клауде, так и на серверах. Мне пришлось объединять данные из клаудной и серверной Jira и устанавливать объединенные данные обратно на Клауд. Помимо стандартных данных Jira мне еще было необходимо объединить данные из Tempo плагина. В этой статье я расскажу, как я сделал объединение и миграцию данных Tempo.
Я поднял две Jira со следующей конфигурацией: Jira Software 7.11.2 и Jira Service Desk 3.14.2. Затем я снял бэкап с Jira Cloud и установил его на первый инстанс, затем я снял бэкап с Jira Server и установил его на второй инстанс. После этого я перенес данные со второго инстанса на первый с помощью плагина Configuration Manager (хотя можно было бы и воспользоваться плагином Project Configurator).
В результате я обнаружил, что на первом инстансе, где уже находились объединенные данные, готовые к переносу на Клауд, отсутствуют следующие данные плагина Tempo:
Нужно было заполнить эти данные при миграции.
С акаунтами мне повезло. В плагине Tempo есть встроенная функциональность по экспорту и импорту акаунтов.
Все, что мне нужно было сделать, это перед установкой объединенных данных в Jira Cloud экспортировать акаунты из Jira Cloud и Jira Server в файлы, а затем, после загрузки объединенных данных в Jira Cloud, импортировать эти файлы в Клауд.
Была только одна проблема, что некоторые ключи акаунтов в Jira Cloud и Jira Server совпадали, поэтому мне нужно было в одном их файлов эти ключи поменять. Иначе при импорте данных акаунта с одинаковыми ключами акаунты будут либо обновлены, либо заархивированы, а мне ни одни из этих вариантов не подходил.
С командами было сложнее. Никакой встроенной функциональности по переносу команд нет. Поэтому пришлось использовать Tempo Rest Api для получения данных по командам, а затем создавать эти команды в Jira Cloud.
Я использовал следующие Rest вызовы:
Я также хотел использовать Tempo Rest Api для установки разрешений команды, но обнаружил баг в этом Api.
Так как на объединенном инстансе 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 перед тем, как делать миграцию.
Это было сделано следующим образом:
Затем после того, как я установил бэкап с объединенными данным, я удалил все записи о работе, которые были добавлены от стандартного пользователя плагина 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. Надеюсь, что эта информация будет полезна.
Плагины 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 перед тем, как делать миграцию.
Это было сделано следующим образом:
- Я нашел все ишью в Jira Cloud, где пользователь записи о работе был пользователь плагина Tempo. Сделал я это с помощью стандартного Jira Core Rest вызова.
- Затем я получил все Jira ид записей о работе из полученных ишью в пункте 1 с помощью вот этого Rest вызова.
- Затем я получил данные из плагина 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)
GiAS
08.10.2018 14:31Замечательный плагин, вот только он все worklogs делает от имени себя и комментарии к ним заменяет на «time-tracking», а информацию о пользователе/комментарии хранит где-то у себя. Чем ломает работу других плагинов. Не надо так.
gecube
Я почуствовал себя лохом, т.к. пользуюсь Atlassian и не знаю — что же это за зверь такой — Tempo плагин. А может их и несколько вовсе? А может он настолько крутой, что нужно срочно брать и его докупать!? Не знаю. В общем, без двух предложений про этот плагин статья не имеет никакого смысла :-(
nick7ikin
на самом деле у Tempo семейство плагинов. Их основное назначение — планирование и отчетность ресурсов компании/проекта. В статье скорее всего имеется в виду плагин Tempo Timesheets, который предоставляет расширенные возможности для логирования времени и формированию отчетов по сравнению со стандартными средствами Jira. Предоставляет возможности по блокированию возможности логировать время при наступлении определенной даты, например начаал месяца/недели и возможность выдавать персональные права на дологирование, если кто-то не успел залогироваться. Есть механизм подтверждения логов другим сотрудником…
gecube
Спасибо за комментарий. Просто автор статьи пишет про «плагин Tempo» в единственном числе. Угадать его мысли — невозможно. Поэтому я и попросил сделать краткую заметку про «плагин Tempo» (предполагая, что их несколько разных для разных целей).