Тикет в джире что это
Использование Jira Query Language на практике
Меня зовут Сергей Раков, я руководитель B2G-направления в компании «Ростелеком ИТ». Я хочу рассказать про язык Jira Query Language (JQL): как им пользоваться на практике, основные приемы, с какими проблемами мы сталкивались и как их решали.
Оригинал картинки взят у deviniti.com/atlassian
Таск-трекеров очень много, каждый подходит для решения одних задач и не очень помогает решать другие. Многими из них мы пользовались, но сейчас остановились на Jira — она наш основной инструмент. Лично мне очень нравится ее язык JQL, который сильно упрощает работу и позволяет из коробки иметь мощный и гибкий инструмент для поиска тикетов.
Из коробки в Jira существуют базовый и продвинутый поиски. Эти два варианта поиска позволяют решить бóльшую часть стоящих перед пользователем задач. Базовый поиск привычен глазу любого человека, кто хоть раз пользовался услугами интернет-магазинов — работает по точно такой же простой схеме. Есть множество фильтров: по проектам, типам задач, по исполнителю и статусу. Также можно добавить дополнительные поля по критериям, которые поддерживаются Jira.
Но возникает проблема, если нужно выйти за рамки базовых запросов. Например, если мы хотим найти задачи, которые были на конкретном исполнителе когда-либо, или найти все задачи, исключая один проект. Сделать хитрую выборку для проекта с одним статусом задач и исполнителем и еще одним исполнителем и другим статусом задач силами базового поиска уже сделать нельзя.
На помощь приходит продвинутый поиск. Синтаксис JQL очень похож на SQL. Но в JQL не нужно выбирать конкретные поля, которые будем селектить, указывать таблицы и базы данных, из которых будем выводить. Мы указываем только блок с условиями и работаем с сортировкой — все остальное Jira автоматически делает сама.
Jira при вводе в строку поиска сама выдает подсказки всех возможных значений, которые вы ищете: как по полям, так и по значениям этих полей. Для себя я недавно открыл интересное системное поле lastViewed. Jira хранит историю ваших просмотров тикетов.
Здесь представлены два варианта составления фильтров для просмотра последних задач. Первый — мой вариант с lastViewed, где Jira выдаст просмотренные мной задачи за последние семь дней, отсортированные по убыванию. Этот фильтр настроен на моем дашборде в виде гаджета, и я к нему часто прибегаю. Потому что тикет закрылся, вкладку и номер не запомнил, быстро открыл, посмотрел, какой был последний тикет.
Есть стандартный фильтр Viewed Recently. Он использует функцию IssueHistory(), сортировка тоже производится по полю lastViewed. Результат одинаковый, но способ, даже в Jira, можно использовать разный. Стоит отметить, что поле LastViewed и IssueHistory() возвращают только вашу историю просмотра — историю третьих лиц таким образом посмотреть не получится.
По большей части в Jira все операторы стандартные. Мне больше всего нравятся операторы WAS, WAS IN, WAS NOT IN, WAS NOT, CHANGED, потому что они работают с временем. В обычных базах данных такой возможности нет.
Jira из коробки позволяет работать с историческими данными. С помощью оператора WAS можно найти тикеты, где исполнителем был и есть User1. Если тикет был на мне, а потом перешел на кого-то еще, запрос покажет, что этот тикет когда-то был на мне. Понятно, что для более подробной выборки нужно добавить еще какие-нибудь условия, но мы к этому еще подойдем.
Правда, есть одна оговорка: Jira не хранит историю для текстовых полей: названий тикетов и их описаний. Там нельзя написать: «Выведи мне тикеты, в которых поле Summary содержало слово “Ростелеком”».
Как мы обрабатываем жалобы пользователей с помощью JIRA (REST API)
В наше время мало какой веб-сервис или приложение обходится без функционала, где пользователи могут пожаловаться (уведомить, зарепортить) на различные виды контента, будь то грамматическая ошибка в тексте, ошибочные формулировки, неинтересный или не информативный контент (как упражнение, урок, статья, обучающий материал либо часть функционала). Возможность “сообщить о проблеме” является неотъемлемой частью вовлечения пользователей в продукт, реализации одной из форм сбора обратной связи и возможности улучшить свое приложение в целом.
Все жалобы пользователей должны где-то храниться, быть приоритезированы, удобно отслеживаться, и, более того, должны быть вовремя обработаны. Но не всегда есть возможность выделить достаточно ресурсов на разработку и поддержание подобной системы, ведь всегда найдется задача в бэклоге с более высоким приоритетом. Ниже я расскажу, как мы достаточно эффективно и быстро решили эту задачу в Uxcel используя JIRA REST API.
Для чего нам “Report a problem”?
Добавим немного контекста — для чего мы предоставляем функционал жалоб и что нам нужно?
Uxcel — веб-сервис для обучения UI/UX в игровой форме. Обучающим элементом у нас является “Практика” — в большинстве случаев это 2 изображения, где одно верное, а другое — нет. Что позволяет натренировать глаз находить недочеты даже в визуально идентичных элементах. Каждая практика помимо изображений имеет подсказку (hint — наводку на верный ответ) и описание (description) с теорией, касающейся данной задачи.
Поскольку число практик исчисляется тысячами — это означает, что где-то может быть допущена грамматическая ошибка, а где-то недостаточно понятное пользователю изображение, подсказка или теория, поэтому очень важно учесть мнение каждого для поддержания эталонного контента. Для всех этих случаев нужно дать возможность “Сообщить о проблеме” прямо во время прохождения практик, не отрываясь от процесса, максимально быстро и удобно. Модераторам же нужно иметь возможность просматривать список практик с жалобами, фильтровать, находить наиболее популярные проблемные, отслеживать текущий статус и закрывать жалобы, сохраняя историю.
Чтобы не изобретать велосипед со своими бордами, тикетами и backlog-ом, а также чтобы хранить все задачи команд в одной системе и даже в общих спринтах, было решено для этих целей использовать JIRA + REST API.
Организация тикетов в JIRA
Для каждой практики у которой есть хотя бы 1 жалоба создается BUG в JIRA в выделенном эпике Practices Reports. А сами жалобы хранятся в виде комментариев к соответствующим багам-практикам. В дополнение к этому, для разных видов практик добавляется Label (в нашем случае такие как: Course, Gym, UEye). Общая логика представлена на схеме ниже:
Таким образом, контент-команда выбирает наиболее приоритетные практики (в виде багов) для исправления в каждом спринте.
А теперь давайте взглянем на технические подробности реализации.
Интеграция с JIRA REST API
Первым делом нужно создать API token в JIRA, чтобы получить доступ к JIRA API. Для использования на продакшене рекомендую создать отдельного пользователя от имени которого и будут создаваться тикеты, иначе придется отбиваться от постоянных уведомлений, в то время как для отдельного пользователя их проще сразу все отключить.
Получение API токена:
Готово. Сохраняем куда-нибудь созданный токен, терять его нельзя.
Теперь можно выполнять API запросы к JIRA. В каждый запрос передается заголовок, содержащий емейл (пользователя для которого был создан токен) и сам токен — их передаем посредством реализации HTTP basic authentication.
Пример кода (весь код на TypeScript для NodeJS):
Примечание: для хранения ключей и паролей мы используем AWS Secrets Manager. Прямо в коде такие данные хранить не безопасно. Больше информации тут.
Создание бага через API
Осталось совсем немного подготовки. Для того чтобы создать баг, нам нужно знать его Issue ID в JIRA. Один из способов его узнать — вызвать GET запрос на получение информации обо всех типах:
Поскольку это разовая операция, то чтобы не писать код можно воспользоваться Postman:
Во вкладке Authorization выбираем Type: Basic Auth, вводим email и api token.
В ответе нас интересует эта часть:
После того как узнали Issue Id типа BUG (“10001”) нам нужно узнать Project Id, к которому баг будет принадлежать. Похожим образом можем получить список всех проектов и найти id нужного.
Для этого делаем GET запрос на
И последний подготовительный шаг: как я выше упоминал, мы храним баги в отдельном эпике (Jira Epic). Его id знать не обязательно, достаточно скопировать его Key (расположен перед названием эпика, либо в адресной строке, например UX-1).
Все готово к созданию первого бага через API.
Я использовал npm пакет Got для создания HTTP запросов для NodeJS.
Баг создан. Далее рассмотрим остальные методы необходимые для настройки полного цикла обработки жалоб и ведения их в JIRA, такие как: Поиск, Обновление статуса, Обновление информации, Добавление комментария к багу.
Поиск бага через API
Поиск бага является первоначальной операцией в API обработки пользовательской жалобы. Необходимо убедиться, что для обжалованной практики не существует тикета, только в этом случае создаем его.
В случае если для практики баг найден, нужно обновить его статус, если проблема была решена и баг находился в статусе CLOSED.
Обновление статуса бага через API
Чтобы обновить статус, воспользуемся Transitions. Но для этого нужно узнать Status ID для TODO / OPENED статуса (статус зависит от настроек JIRA).
Возвращаемся к Postman:
По id проекта получаем все статусы, находим статус, который указывает на открытое состояние тикета и сохраняем его id.
Запрос на перевод бага в открытый статус:
Следующий шаг после перевода найденного бага в открытое состояние — обновление названия (а если нужно, то и описания либо приоритета).
Обновление названия бага через API
Названия багов должны отражать текущее состояние проблемы, помимо id и названия практики в названии бага можно хранить и статистику для более удобного поиска и просмотра открытых жалоб на борде. Под статистикой в нашем случае подразумевается количество жалоб на данную практику и процент верных ответов. Так, если у практики число верных ответов достаточно низкое либо же число жалоб больше n — можно повышать приоритет.
Код вызова API для обновления бага:
Далее добавим детали самой жалобы в виде комментария к уже подготовленному багу.
Добавление комментария через API
Каждая жалоба пользователя хранится в виде комментария к багу-практике.
Код создания комментария:
Объект comment формируется в виде Atlassian Document Format.
На сайте так же есть Builder, который значительно упрощает генерацию объекта: просто форматируем текст под свои нужды в редакторе — при этом параллельно создается итоговый JSON объект.
Готово! Теперь можно принимать, хранить, обрабатывать, закидывать в спринты и удобно искать жалобы пользователей используя JIRA.
Как у нас выглядят жалобы в виде комментариев:
Итоговый вид нашего списка багов в JIRA (название содержит id, #N — число жалоб, % — верных ответов):
Дальше все зависит от вашей фантазии и требований. Например, можно:
Всем спасибо за внимание! Надеюсь, статья была для вас полезной 🙂
С радостью отвечу на ваши вопросы!
Настройка Jira под ваши нужды. Cовершенный флоу и идеальный тикет
Если вы работаете в IT-компании, то, скорее всего, ваши процессы построены вокруг известного продукта Atlassian — Jira. На рынке есть множество таск-трекеров для решения тех же задач, в том числе open-source-решения (Trac, Redmine, Bugzilla), но, пожалуй, именно Jira имеет сегодня самое широкое распространение.
Меня зовут Дмитрий Семенихин, я тимлид в компании Badoo. В небольшом цикле статей я расскажу, как именно мы используем Jira, как настраивали её под свои процессы, что хорошего «прикрутили» сверху и как тем самым превратили issue-трекер в единый центр коммуникаций по задаче и упростили себе жизнь. В этой статье вы увидите наш флоу изнутри, узнаете, как можно «докрутить» свою Jira, и прочтёте о дополнительных возможностях инструмента, о которых могли не знать.
Статья ориентирована прежде всего на тех, кто уже использует Jira, но, возможно, испытывает сложности с интеграцией её стандартных возможностей в существующие в компании процессы. Также статья может быть полезна компаниям, которые используют другие таск-трекеры, но столкнулись с некоторыми ограничениями и подумывают о смене решения. Статья построена не по принципу «проблема — решение», в ней я описываю сложившийся инструментарий и фичи, построенные нами вокруг Jira, а также технологии, которые мы использовали для их реализации.
Дополнительные возможности Jira
Чтобы последующий текст был более понятным, давайте разберёмся, какие инструменты предоставляет нам Jira для реализации нестандартных хотелок — тех, что выходят за рамки стандартного функционала Jira.
REST API
В общем случае вызов команды API — это HTTP-запрос к URL API с указанием метода (GET, PUT, POST and DELETE), команды и тела запроса. Тело запроса, а также ответ API — в JSON-формате. Пример запроса, который вернёт JSON-представление тикета:
С помощью API вы можете, используя скрипты на любом языке программирования:
Мы написали собственный высокоуровневый Jira API-клиент на PHP, который реализует все необходимые нам команды. Вот пример команд для работы с комментариями:
Webhooks
С помощью webhook можно настроить вызов внешней callback-функции на вашем хосте на различные события в Jira. При этом можно настроить сколько угодно таких правил таким образом, что различные URL будут «дёргаться» для разных событий и для тикетов, которые соответствуют указанному в webhook фильтру. Интерфейс настройки webhooks доступен администратору Jira.
В результате можно создавать правила вроде этого:
Name: “SRV — New Feature created/updated”
URL: www.myremoteapp.com/webhookreceiver
Scope: Project = SRV AND type in (‘New Feature’)
Events: Issue Updated, Issue Created
В данном примере указанный URL будет вызываться для событий создания и изменения тикетов, соответствующих фильтру Scope. При этом в теле запроса будет содержаться вся необходимая информация о том, что именно изменилось и какое событие произошло.
Тут важно понимать, что Jira не гарантирует, что ваше событие будет доставлено. Если внешний URL не ответил или ответил с ошибкой, это нигде видно не будет (кроме логов, пожалуй). Поэтому обработчик событий webhook должен быть максимально надёжным. Например, события можно складывать в очередь и пытаться обработать до тех пор, пока это не закончится успехом. Это поможет решить проблемы с временно недоступными сервисами, например, какой-либо внешней базой данных, необходимой для правильной обработки события.
Подробная документация о webhooks представлена по ссылке.
ScriptRunner
Это плагин к Jira, очень мощный инструмент, который позволяет кастомизировать в Jira очень многое (в том числе он способен заменить собой webhooks). Для пользования этим плагином требуется знание Groovy. Основное преимущество инструмента для нас состоит в том, что можно встраивать во флоу кастомную логику в режиме онлайн. Код вашего скрипта будет исполняться сразу в среде Jira в ответ на определённое действие. Например, можно сделать в интерфейсе тикета свою кнопку, клик по которой будет создавать связанные с текущей задачей тикеты или запускать юнит-тесты для данной задачи. И если вдруг что-то пойдёт не так, вы как пользователь сразу об этом узнаете.
Желающие могут ознакомиться с документацией.
Флоу: что скрыто под капотом
А теперь о том, как мы применяем дополнительные возможности Jira в наших проектах. Рассмотрим это в контексте прохождения нашего типичного тикета по флоу от создания до закрытия. Заодно и про сам флоу расскажу.
Open/Backlog
Итак, сначала тикет попадает в беклог новых тикетов со статусом Open. Далее лид компонента, увидев новый тикет на своём дашборде, принимает решение: назначить тикет прямо сейчас разработчику либо отправить его в беклог известных тикетов (статус Backlog), чтобы назначить его позже, когда появится свободный разработчик и более приоритетные тикеты будут закрыты. Это может показаться странным, так как кажется логичным делать наоборот: создавать тикеты в статусе Backlog, а потом переводить в статус Open. Но у нас прижилась именно эта схема. Она позволяет легко настроить фильтры, чтобы сократить время принятия решения по новым тикетам. Пример JQL-фильтра, который показывает новые задачи лиду:
Project = SRV AND assignee is EMPTY AND status in (Open)
In Progress
Надо отметить, что у нас работа над каждой задачей ведётся в отдельной Git-ветке. Насчёт этого у нас есть соглашение, что имя ветки в начале должно содержать номер тикета. Например, SRV-123_new_super_feature. Также комментари к каждому коммиту в ветку должны содержать номер тикета в формате [SRV-123]:
Эти требования контролируются Git-хуками. Например, вот содержимое prepare-commit-msg, который подготавливает комментарий к коммиту, получая номер тикета из имени текущей ветки:
Если коммит с «неправильным» комментарием попытаться запушить, такой пуш будет отклонён. Также отклонена будет попытка запушить ветку без номера тикета в начале.
Когда тикет попадает на разработчика, первым делом он декомпозируется. Результатом декомпозиции является представление разработчика о способах решения задачи и о том, сколько времени займёт решение. После того как все основные детали выяснены, тикет переводится в статус In Progress, а разработчик начинает писать код.
У нас принято выставлять задаче due date в момент, когда она переводится в статус In Progress. Если же разработчик этого не сделал, ему придёт напоминание в корпоративный мессенджер HipChat. Специальный скрипт раз в два часа:
Что ещё?
Ещё с помощью API и webhooks Jira мы делаем такие вещи:
Итоги
Jira — прекрасный инструмент, который в стандартной поставке позволяет решать большинство проблем, связанных с организацией ведения проектов. Но, как известно, в любом бизнесе есть свои нюансы. И для адаптации Jira к особенностям ваших процессов этот продукт обладает дополнительными возможностями, которые в умелых руках позволят вам решить практически любую проблему.
В следующей статье я планирую поделиться нашим опытом по настройке дашбордов — лидских и девелоперских. Также расскажу про настройку уведомлений в Jira и поделюсь секретами о том, как мы организуем синхронизацию работы разных команд на базе Jira. Надеюсь, что-то из нашего опыта пригодится и вам.
Тикет в джире что это
Jira — коммерческая система отслеживания ошибок, предназначена для организации взаимодействия с пользователями, хотя в некоторых случаях используется и для управления проектами.
Разработана компанией Atlassian, является одним из двух её основных продуктов (наряду с вики-системой Confluence). Имеет веб-интерфейс.
Название системы получено путём усечения слова «Gojira» — японского имени монстра Годзилла, что, в свою очередь, является отсылкой к названию конкурирующего продукта — Bugzilla; создавалась в качестве замены Bugzilla и во многом повторяет её архитектуру.
Система позволяет работать с несколькими проектами. Для каждого из проектов создаёт и ведёт схемы безопасности и схемы оповещения.
Первый выпуск — в 2002 году. Изначально применялась в процессах разработки программного обеспечения, впоследствии нашла применение в качестве инструмента управления проблемами, задачами, проектами в различных отраслях.
Процесс универсализации ускорился после запуска Atlassian Marketplace в 2012 году, который позволил сторонним разработчикам предлагать плагины для Jira BigPicture, Portfolio for Jira, Structure и Tempo Planner — основные плагины для управления проектами для Jira. До версии 3.13.5 (включительно) различались редакции Enterprise, Professional и Standard, после — осталась только редакция Enterprise (для крупных организаций).
Реализация
Система основана на Java EE и работает на нескольких популярных системах управления базами данных и операционных системах.
Ticket
Основной элемент учёта в системе — задача (англ. ticket или issue).
Задача содержит название проекта, тему, тип, приоритет, компоненты и содержание.
Задача может быть расширена дополнительными полями (также и новые пользовательские поля могут быть определены), приложениями (например — фотографиями, скриншотами) или комментариями.
Задача может редактироваться или просто изменять статус, например, из «открыт» в «закрыт».
Какие переходы между состояниями возможны, определяется через настраиваемый поток операций.
Любые изменения в задаче протоколируются в журнал.
Конфигурация
Jira имеет большое количество возможностей конфигурации: для каждого приложения может быть определён отдельный тип задачи с собственным workflow, набором статусов, одним или несколькими видами представления (англ. screens). Кроме того, с помощью так называемых «схем» можно определить для каждого индивидуального Jira-проекта собственные права доступа, поведение и видимость полей и многое другое.
Применение
Благодаря универсальному подходу можно приспособить Jira для многих непрофильных задач, например, управления требованиями, управления рисками, вплоть до реализации небольшой системы бронирования, автоматизации процесса рекрутинга.
Интеграция
Для сторонних разработчиков предоставляются средства разработки расширений системы — плагинов. Разработчики расширений могут выкладывать плагины для продажи на специальный раздел сайта Atlassian.
Создать свой фильтр
Не всегда удобно искать свои таски на Kanban доске.
Проще создать свои фильтры, которые будут показывать нужную именно вам информацию
Filters → Advanced issue search
В поисковой строке будет текст, например
order by created DESC
Удалите его и можно начинать писать своё условие на языке JQL
Посмотреть все свои тикеты
Чтобы посмотреть все тикеты на которые вы были назначены достаточно выполнить
project = TopBicycle AND assignee = currentUser()
Более сложный пример
Допустим, вам нужно найти все активные таски для проекта TopBicycle в которых вы назначены тестировщиком
project = TopBicycle AND «Tester[User Picker (single user)]» = currentUser() AND status not in (Done, Rejected)
Нажмите ENTER и убедитесь, что фильтр сработал
Нажмите Save as и в окне Save Filter введите в поле Filter Name* название для вашего фильтра
Нажмите ENTER и теперь в Filters должен появиться только что созданный фильтр.
Для связи различных условий доступны логические операторы AND (И) и OR (ИЛИ).
Порядок выведения элементов можно регулировать с помощью ORDER BY
Как только вы напишите project = должен появиться выпадающий список с доступными проектами
Cодержит ключевое слово
Допустим, вам нужно найти все таски в статусе Ready for testing для проекта HeiHei в описании и названии которых встречается SDK
project = HeiHei AND status in («Ready for testing») AND (description
Не содержит ключевое слово
Допустим, вам нужно найти все таски в статусе Ready for testing для проекта HeiHei в описании и названии которых не встречается SDK