как узнать linkid в jira
Общие спринты в Atlassian Jira Software
В этой статье я хотел бы поговорить об Общих Спринтах (Shared Sprints) в Atlassian Jira Software.
Если почитать официальную документацию, например, вот тут, то там не будет такого понятия как общий спринт.
Впервые я встретил термин общий спринт вот тут. В этой статье хорошо рассказано, что такое общие спринты и как с ними жить.
Общие спринты — это важное понятие в Atlassian Jira Software, потому что знакомство с общими спринтами происходит, как правило, неожиданно, и кажется, что что-то пошло не так. Но это не так, и, если знать, как общие спринты работают, то можно их использовать для своих нужд.
В этой статье я покажу на примерах как выглядят общие спринты, и как их отличить от обычных спринтов. А также расскажу про их особенности.
Все примеры в этой статье я пробовал в Jira Software Cloud и в Jira Software Server 7.12.3.
Что такое общий спринт?
Общий спринт — это спринт, который виден на более, чем одной доске.
Например, есть вот такие скриншоты досок:
Можно увидеть, что на досках SCRUM и SCRUM2 есть спринт с названием SCRUM Sprint 3. Этот спринт виден на двух досках. Значит ли что мы видим общий спринт? Нет. В Jira Software может быть два разных спринта с одинаковым наименованием.
Как увидеть ид спринта?
Для того, чтобы понять общий ли спринт перед нами или обычный, мы должны посмотреть ид этих двух спринтов.
Посмотреть ид спринтов можно вот так:
Общий спринт
Теперь давайте посмотрим вот на этот скриншот:
На скриншоте мы видим доску SCRUM, на которой есть два спринта с одинаковым наименованием. И спринт, выделенный красным содержит такой же тикет, как и спринт на доске SCRUM2. Если мы проверим ид этого спринта на доске SCRUM и SCRUM2, то ид совпадут, а значит, что перед нами общий спринт.
Почему у нас один и тот же спринт на двух досках?
project = SCRUM OR priority is not EMPTY ORDER BY Rank ASC
project = SCRUM2 ORDER BY Rank ASC
Мы видим, что фильтр для SCRUM выбирает не только тикеты из проекта SCRUM, но и все тикеты в нашем инстансе Jira, у которых заполнен приоритет, а значит он выбирает и тикеты из проекта SCRUM2. Поэтому тикеты из проекта SCRUM2 видны и на доске SCRUM, и на доске SCRUM2. И поэтому если мы заполним поле Sprint в одном из тикетов, этот спринт появится на двух досках.
Спринт создается из доски и содержит ссылку на доску, из которой он создан. Для этого можно выполнить, например, rest/agile/1.0/sprint/sprintId и увидеть доску, из который спринт был создан. В нашем случае мы получим вот такой результат:
originBoardId = 3, а это доска SCRUM2. Это означает, что спринт изначально был создан на доске SCRUM2, а на доске SCRUM он появился потому, что тикет из спринта есть как на доске SCRUM2, так и на доске SCRUM.
Как себя ведут общие спринты?
Если внести какие-то изменения в общий спринт на любой из досок, на которой спринт виден, то изменения будут видны на всех досках.
Например, если мы переименуем спринт на доске SCRUM, то он переименуется и на доске SCRUM2. Если мы закроем спринт на доске SCRUM, то он и закроется на доске SCRUM.
Именно это поведение обычно встречают пользователи. Они работают со спринтом и вдруг спринт закрывается. Никто из команды его не закрывал. В результате оказывается, что спринт был закрыт из другой доски, у которой фильтр выбирает тикеты из этого проекта.
Как можно использовать общие спринты?
Допустим у нас есть несколько команд, и у каждой команды есть свой проект. Каждая команда создает доску и работает на этой доске. Мы хотим увидеть спринты всех команд. Как мы это можем сделать?
Настройка 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 (простым языком). Часть 2: Продвинутый поиск
Структуру JQL-запросов без примеров сложно понять специалистам, не знакомым ранее с JIRA.
Мы уже успели рассказать про быстрый и базовый поиск. Теперь же прейдем к самому мощному из трех методов — к продвинутому поиску.
В этом режиме вы можете указывать критерии, которые нельзя задавать в остальных предыдущих двух режимах (например, сортировку ORDER BY). Но придётся освоить создание структурированных запросов с помощью JIRA Query Language (JQL).
А если вы находитесь в режиме «базового» поиска, нажмите кнопку «Продвинутый»
1. Создание JQL-запросов
Простейший запрос на JQL состоит из поля, за которым следует оператор, а затем одно или несколько допустимых значений для этого поля. Например:
Такой запрос поможет найти все задачи проекта «YAT». Здесь использовано поле «project», оператор эквивалента «=» и допустимое значение «YAT».
Более сложный запрос может выглядеть так:
project = «YAT» AND assignee = currentuser()
Так мы отберём все задачи проекта «YAT», назначенные на текущего пользователя
(то есть на вас). В запросе содержатся: логический оператор «AND», поле «assignee» для отбора задач по текущему пользователю, оператор эквивалента «=» и функция «currentuser()», возвращающая имя текущего пользователя системы.
При создании запроса в режиме «продвинутого» поиска JIRA показывает список всех возможных операторов для поля запроса.
Также JIRA показывает список доступных значений для полей «AffectedVersion«, «FixVersion«, «Components«, кастомных полей формата «Version» и выпадающих списков.
При использовании в поиске полей формата «User» JIRA позволяет найти необходимого пользователя по его фамилии.
Вы можете использовать круглые скобки в сложных JQL-запросах. Например, если хотите найти все разрешенные задачи в проекте «SysAdmin», а также все задачи (любого статуса, любого проекта), назначенные в настоящее время системному администратору (admin), то можете использовать круглые скобки, обозначая приоритет логических операторов в запросе.
(project=SysAdmin AND status=resolved) OR assignee=admin
В JQL есть зарезервированные символы.
Внимание!
Также в JIRA есть зарезервированные слова.
Если в тексте поиска упомянуто одно из перечисленных ниже слов, этот текст нужно выделить либо двойными кавычками («. «), либо одинарными (‘. ‘).
Список зарезервированных слов:
| A | «abort», «access», «add», «after», «alias», «all», «alter», «and», «any», «as», «asc», «audit», «avg» |
| B | «before», «begin», «between», «boolean», «break», «by», «byte» |
| C | «catch», «cf», «char», «character», «check», «checkpoint», «collate», «collation», «column», «commit», «connect», «continue», «count», «create», «current» |
| D | «date», «decimal», «declare», «decrement», «default», «defaults», «define», «delete», «delimiter», «desc», «difference», «distinct», «divide», «do», «double», «drop» |
| E | «else», «empty», «encoding», «end», «equals», «escape», «exclusive», «exec», «execute», «exists», «explain» |
| F | «false», «fetch», «file», «field», «first», «float», «for», «from», «function» |
| H | «having» |
| I | «identified», «if», «immediate», «in», «increment», «index», «initial», «inner», «inout», «input», «insert», «int», «integer», «intersect», «intersection», «into», «is», «isempty», «isnull» |
| J | «join» |
| L | «last», «left», «less», «like», «limit», «lock», «long» |
| M | «max», «min», «minus», «mode», «modify», «modulo», «more», «multiply» |
| N | «next», «noaudit», «not», «notin», «nowait», «null», «number» |
| O | «object», «of», «on», «option», «or», «order», «outer», «output» |
| P | «power», «previous», «prior», «privileges», «public» |
| R | «raise», «raw», «remainder», «rename», «resource», «return», «returns», «revoke», «right», «row», «rowid», «rownum», «rows» |
| S | «select», «session», «set», «share», «size», «sqrt», «start», «strict», «string», «subtract», «sum», «synonym» |
| T | «table», «then», «to», «trans», «transaction», «trigger», «true» |
| U | «uid», «union», «unique», «update», «user» |
| V | «validate», «values», «view» |
| W | «when», «whenever», «where», «while», «with» |
2. Использование шаблонов для поиска по тексту
Специальные символы могут быть использованы для определения шаблонов поиска по тексту. Рассмотрим несколько примеров:
| Знак | Область применения и описание | Пример |
|---|---|---|
| ? | «?» используется для замены одного символа в шаблоне. Например, написание слов «text» и «test» отличается одним символом. Для поиска обоих вариантов достаточно задать шаблон: te?t | summary |
«te?t»
нуля или нескольких символов. Например, для отбора текста
«Windows», «Win95» или «WindowsNT» можно использовать
шаблон: win*
Для отбора текста «Win95» или «Windows95»
можно использовать шаблон: wi*95
» может быть использована для задания
нечетких поисковых шаблонов. В этом случае символ «
»
подставляется в конце нужного слова. Например,
чтобы найти термин, орфографически похожий на «roam»,
используйте шаблон: roam
В результате могут быть найдены слова «foam» или «roams».
3. Логические операторы JQL
| Оператор | Описание | Пример |
|---|---|---|
| AND | Логическая операция «И», соединяющая два или несколько условий. Используется для уточнения условий отбора. | project = «YAT» and status = «Оpen» — отобрать все задачи проекта «YAT» в статусе «Open» |
| OR | Логическая операция «ИЛИ», соединяющая два или несколько условий. | reporter = demo_1 or reporter = demo_2 — отобрать все задачи проекта, автором которых является пользователь demo_1 или пользователь demo_2. |
| NOT | Для реверсирования результата логического условия. | not assignee = demo_1 — отобрать все задачи, исполнителем которых не является пользователь demo_1. |
| ORDER BY | Сортировать по. |
По умолчанию будет использоваться собственный порядок,
применяемый для этого поля. Вы можете переопределить направление сортировки —
по возрастанию («asc») или убыванию («desc»).
отобрать все задачи, у которых пустые поля «Due date» (Срок исполнения),
отсортировать результаты выборки по полю «Created» (Создано).
duedate = empty order by created, priority desc —
отобрать все задачи, у которых пустые поля «Due date» (Срок исполнения),
отсортировать результаты выборки по полю «Created» (Создано)
в собственном порядке, затем по полю «Priority» (Приоритет)
в убывающем порядке.
| Оператор | Описание | Пример |
|---|---|---|
| = | Эквивалент. |
Используется для задания
критерия полного соответствия.
либо можно использовать запись
NOT reporter = demo_1
Используется для создания выражений
с полями формата «Version»,
формата дата-время и числовых полей.
duedate > now()
Используется для создания выражений
с полями формата «Version»,
формата дата-время и числовых полей.
duedate >= «2008/12/31»
created >= «-5d»
currentLogin()
Внимание
Самая ранняя не выпущенная версия определяется порядком, а не датами.
Применяется для создания выражений с полями «AffectedVersion» (Проявляется в версиях»), «FixVersion» (Исправлено в версиях), кастомными полями формата Version.
Unreleased
Version(project)
earliestUnreleased
Version
(ABC)
fixVersion =
earliestUnreleased
Version
(ABC)
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата даты-времени.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 день.
Внимание
Самая последняя выпущенная версия определяется порядком, а не датами.
fixVersion =
latestReleased
Version(ABC)
Внимание
LinkType чувствителен к регистру.
(issueKey)
linkedIssues
(issueKey,linkType)
(ABC-123,
«is duplicated by»)
Используется для создания выражений с полями «Reporter» (Автор), «Assignee» (Исполнитель), «Voter», «Watcher» и кастомными полями формата «User».
(Group)
in membersOf(QA)
Для отбора задач JIRA Service Desk, требующих согласования текущего пользователя или уже согласованных текущим пользователем.
Применяется к полям типа «Approvals».
myApproval()
Для отбора задач JIRA Service Desk, требующих согласования текущего пользователя.
Применяется к полям типа «Approvals».
myPending()
created >
startOfDay
(«-3d») – задачи,
созданные за
последние три дня.
Month()
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата дата-время.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 месяц.
created > startOfMonth
(«+14d») — задачи,
созданные с пятнадцатого
числа текущего месяца.
Week()
Используется в выражениях с полями
«Created» (Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата даты-времени.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 неделя.
created >
startOfWeek
(«-1») — задачи,
дата создания которых
старше начала
прошлой недели.
Year()
Используется в выражениях с полями
«Created»
(Создано),
«Due Date»
(Срок исполнения),
«Resolved»
(Дата решения),
«Updated» (Обновлено), кастомными полями формата дата-время.
где inc —
опциональный
инкримент
(±)nn(y|M|w|d|h|m).
Если спецификатор единицы
измерения времени опущен,
по умолчанию используется
естественный период функции,
т. е. 1 год.
created >
startOfYear
(«-1») — задачи,
дата создания
которых старше
начала прошлого года.
IssueTypes()
IssueTypes()
subtask
IssueTypes()
Versions()
Применяется для создания выражений с полями «AffectedVersion» (Проявляется в версиях), «FixVersion» (Исправлено в версиях), кастомными полями формата Version.
используется
для отбора задач
по всем проектам.
unreleased
Versions
(project)
unreleased
Versions(ABC)
Issues()
votedIssues()
Issues()
watchedIssues()
Надеюсь, что разбор продвинутого режима поможет вам при поиске задач.
Пользуйтесь и не теряйтесь 😉