Как с помощью SQL отследить все изменения, влияющие на scope версии в JIRA. Часть I
В данной статье затронем вопрос, связанный с version scope management
Представим, что очередная версия в JIRA запланирована, все естимейты указаны, определена дата релиза и команда приступает к выполнению задач в текущей версии. Пока все идет своим чередом, постепенно объем работ осваивается, ничто не угрожает срыву озвученных сроков. Но стоит только на пару дней отвлечься от контроля скоупа версии (например, переключившись на другой проект), как начинает происходить какая то магия. Каким-то загадочным образом в скоупе версии появляются новые задачи или баги, естимейты запросов меняются явно не в пользу своевременного завершения версии.
Вот наиболее распространенные причины такого явления:
- кто-то из разработчиков или QA решил, что найденный баг критичен для версии и включил его в версию, или еще хуже решил, что поставленная задача не важна для версии и перенес на следующую версию;
- аналитик только что от приехал от заказчика и пару новоиспеченных change request-ов могут оказаться в текущей версии;
- какая-то задача ошибочно оказалась перемещенной из другого проекта или ей просто ошибочно указали версию при создании. Разработчик увидел задачу и приступил к ее реализации;
- в процессе реализации задачи разработчик понял, что недооценил время на выполнение задачи и увеличил его в два раза, ничего не сообщив менеджеру.
Есть и другие кейсы, которые могут влиять на изменение скоупа вашей версии.
Безусловно, многие проблемы можно решить правами доступа и запретить корректировать оценки или менять версию. Менеджер может оставить это право только за собой. Но стоит ли? Есть множество других ситуаций, когда у команды должны быть такие права. Можно поступить иначе — отслеживать изменения скоупа версии.
В JIRA нет стандартных инструментов, позволяющих получить список изменений в скопе версий за определенный промежуток времени. Снова SQL нам в помощь. С точки зрения выполнения атомарных операций, в JIRA есть несколько действий, которые могут приводить к изменению скоупа версии, а именно:
- создание issue сразу с указанием версии;
- добавление issue в версию;
- перемещение issue из другого проекта в версию;
- удаление issue из версии;
- добавление/удаление/изменение естимейта в issue, который находится в версии.
В данной статье рассмотрим как с помощью SQL отследить первые 4 типа действий, которые так или иначе связаны или с появлением issue в версии или с его исчезновением. Рассмотрим запрос:
declare @start_date datetime, @end_date datetime, @version nvarchar(100) set @start_date = cast('2017.03.24 13:40:00' AS datetime) set @end_date = cast('2017.03.26 15:55:00' AS datetime) set @version = 'demo_1.0.0' select 'Запрос добавлен в версию' action, p.pkey+'-'+cast(ji.issuenum as nvarchar(100)) 'issue_key', it.pname, cg.AUTHOR, cg.CREATED from changegroup cg, changeitem ci, jiraissue ji, project p, issuetype it where cg.CREATED between @start_date and @end_date and ci.groupid = cg.ID and ci.FIELD = 'Fix Version' and cast(ci.NEWSTRING as nvarchar(100)) = @version and p.ID = ji.PROJECT and ji.ID = cg.issueid and it.ID = ji.issuetype union all select 'Запрос сразу создан в версии' action, p.pkey+'-'+cast(ji.issuenum as nvarchar(100)) 'issue_key', it.pname, ji.CREATOR, ji.CREATED from jiraissue ji, project p, projectversion pv, nodeassociation na, issuetype it where ji.CREATED between @start_date and @end_date and pv.PROJECT = p.ID and pv.vname = @version and na.SOURCE_NODE_ENTITY = 'Issue' and na.SOURCE_NODE_ID = ji.ID and na.SINK_NODE_ENTITY = 'Version' and na.SINK_NODE_ID = pv.ID and it.ID = ji.issuetype and not exists (select 1 from changegroup cg, changeitem ci where cg.issueid = ji.ID and cg.CREATED > ji.CREATED and ci.groupid = cg.ID and ci.FIELD = 'Fix Version' and cast(ci.NEWSTRING as nvarchar(100)) = @version) union all select 'Запрос удален из версии' action, p.pkey+'-'+cast(ji.issuenum as nvarchar(100)) 'issue_key', it.pname, cg.AUTHOR, cg.CREATED from changegroup cg, changeitem ci, jiraissue ji, project p, issuetype it where cg.CREATED between @start_date and @end_date and ci.groupid = cg.ID and ci.FIELD = 'Fix Version' and cast(ci.OLDSTRING as nvarchar(100)) = @version and p.ID = ji.PROJECT and ji.ID = cg.issueid and it.ID = ji.issuetype order by CREATED
Этот запрос получает список всех изменений в скопе произошедших за указанный период в заданной версии. В начале объявляются три переменные: дата начала и дата окончания сравниваемого периода, название версии. Даты можно указать с учетом времени, т.е. вы сможете сравнить скоуп версии даже за последние 15 минут. Как видим, запрос состоит из 3-х частей, результаты которых объединяются с помощью оператора UNION ALL.
Первый подзапрос получает список всех issues, который были добавлены в версии за заданный период. Второй запрос получает список issues, которые были созданы в данном периоде сразу с указанием интересующей версии. И последняя часть запроса отвечает за получения запросов, которые были из версии удалены.
Вот такой полезный SQL-запрос в помощь менеджеру или тимлиду. Копируйте себе и пользуйтесь на здоровье!
В следующей статье рассмотрим запрос, который позволяет отследить все изменения естимейтов в запросах определенной версии, что также напрямую влияет на ее скоуп.