Доступ к базе данных JIRA. Выполняем простой SQL-запрос

Предположим, вы уже столкнулись с ситуацией, когда стандартные инструменты системы JIRA, не справляются с возникшей перед вами задачей. В моей практике часто возникали ситуации, когда по первичным данным из JIRA требовалось выполнить определенную аналитику. При чем — это не обязательно была сложная аналитика. Даже такой простой запрос как «получить список всех проектов, в которых отмечал ворклоги сотрудник А, за такой-то период», уже требует нестандартного подхода, поскольку средствами JIRA ответить на такой вопрос невозможно. В JIRA нужно заглянуть с другой стороны, постучаться напрямую к ее базе данных и получить то что нужно с помощью универсального языка SQL.

Большая серия статей на данном сайте будет посвящена работе с первичными данными с помощью SQL. Но перед тем как выполнить первый SQL запрос нужно добраться до базы данных JIRA. Поэтому в данной статье мы в первую очередь поговорим о доступе к ней. И затем я смогу с чистой совестью ссылаться на данный материал в последующих статьях, напоминая, что сначала нужно решить вопрос с доступом, а потом уже выполнять SQL-запросы.

Архитектура веб-системы JIRA включает реляционную СУБД, в которой хранится вся первичная информация по управлению проектом, накапливаемая в багтрекере. Каждая созданная задача или баг, каждое изменение состояния или атрибута, каждое назначение или смена исполнителя — вся эта информация есть в базе данных JIRA. В качестве хранилища данных могут выступать разные популярные СУБД, такие как Oracle, PostgreSQL, MySQL или SQL Server.

В моем случае СУБД — это SQL Server. В качестве клиентского приложения можно использовать SQL Server Management Studio.

Безусловно база данных вашей корпоративной JIRA «спрятана за семью замками» и по умолчанию вы не подключитесь к ней под своей доменной учетной записью. Наверняка скептически настроенные администраторы и жесткая корпоративная политика запретят вам прямое обращение к базе данны JIRA. С одной стороны все правильно — нельзя направо и налево раздавать доступ к такому важному активу компании. Но с другой стороны — для работы с данными багтрекера нужен весьма ограниченный доступ. Во-первых, нужен доступ только на чтение. Т.е. можно ограничить доступ таким образом, чтобы любые изменения були запрещены. Во-вторых, вся база и не нужна. Как правило, достаточно обращения не более чем к 10-15 ключевым таблицам. В-третьих, в 99% ситуаций нет необходимости в доступе к оперативной базе данных. Это значит, что администраторы могут с определенной периодичностью снимать копию рабочей базы и разворачитвать ее на другом сервере подальше от рабочего. Ну и в-четвертых, совсем для параноиков, с помощью специальных средств профилирования в СУБД можно ограничивать количество обращений к БД, определять график доступа, ограничивать количество выполняемых запросов и т.п.

В моей ситуации оказалось достаточным «во-первых» и «во-вторых» 🙂

Итак, доступ предоставлен. Это значит, что вам известно полное имя сервера базы данных, название базы данных, логин и пароль для подключения. После удачного подключения в SQL Server Management Studio вы можете просмотреть список таблиц.

 

И вот теперь наступило время выполнить первый запрос. Начнем с самого простого запроса: получить общее количество issues в проекте с названием DEMO.

Хотя запрос и простой, для его реализации нам необходимо немного углубиться в изучение структуры базы данных JIRA. Все данные об issues хранятся в таблице jiraissue. Список всех проектов хранится в таблице project. Таблицы jiraissue и project связаны между собой по ключу. Вот как выглядит сокращеная ERD-модель для этих двух таблиц:

schema2

Выполним несколько итераций, двигаясь к поставленной цели.

  1. Получаем общее количество запросов по всем существующим проектам

 

select count(*) from jiraissue ji

 

2. Теперь связываем две таблицы по ключу с помощью оператора join:

 

select count(*) from jiraissue ji

join project p on (p.id = ji.project)

 

3. И наконец, фильтруем толко те запросы, которые относятся к проекту DEMO. Вот наш финальный SQL-запрос:

 

select count(*)

from jiraissue ji

join project p on (p.id = ji.project)

where p.pkey = 'DEMO'

 

Пока мы не превзошли возможностей самой системы JIRA, поскольку данную статистику в ней также можно с легкостью получить. Но в последующих статьях, постепенно двигаясь от простых задач к более сложным, вы и не заметите как будете выполнять более сложную аналитику, характерную именно для вашей модели управления проектами в багтрекинговой системе JIRA.

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