Как с помощью 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-запрос в помощь менеджеру или тимлиду. Копируйте себе и пользуйтесь на здоровье!

В следующей статье рассмотрим запрос, который позволяет отследить все изменения естимейтов в запросах определенной версии, что также напрямую влияет на ее скоуп.