Настройка триггеров рабочих процессов

Триггеры - это мощный инструмент для синхронизации  задач пользователей  JIRA с информацией выбранных ими  инструментах разработки (FishEye / Crucible, Bitbucket и GitHub). Вместо того, чтобы полагаться на разработчиков, которые  вручную обновляют статус проблем после фиксирования кода, завершения обзоров, создания ветвей и т. д., пользователи  могут самостоятельно настроить триггеры в своем рабочем процессе для автоматического перехода к задачам, возникающим при возникновении этих событий в ваших инструментах разработки. Например, вы можете настроить триггер для автоматической передачи проблемы с «Сделать» (To Do) на «В разработке» (In Progress), когда создается ветка.

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

Совет. Если вы интегрируете JIRA с инструментами разработки указанными выше, вы дополнительно включите ряд других функций. К ним относятся информация о разработке, отображаемая по задачам, и возможность создания ветви при начале работы над задачей. Подробную информацию см. в разделе «Оптимизация вашей разработки с JIRA».

Руководство: настройка триггеров

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

• Введение
• Шаг 1. Создание / редактирование рабочего процесса
• Шаг 2. Добавление триггера к переходу
• Шаг 3. Тестирование триггера
• Шаг 4. Добавление остальных триггеров

Введение

Снимок экрана и таблица ниже показывают рабочий процесс и триггеры, аналогичные тем, что вы будете настраивать. Они отражают типичные взаимодействия между JIRA и инструментами разработки в жизненном цикле разработки программного обеспечения. В этом примере используются JIRA (6.3.4), сервер Bitbucket (ранее Stash) и FishEye / Crucible (3.5.2), но вы можете настроить что-то подобное с помощью любого из поддерживаемых инструментов разработки.

 

Шаг 1. Создание / редактирование рабочего процесса

Самый простой способ создать рабочий процесс разработки программного обеспечения - создать новый проект, выбрав тип проекта Software Development. Это создаст ваш новый проект с рабочим процессом разработки программного обеспечения, который идентичен показанному выше.

Если у вас уже есть аналогичный рабочий процесс, перейдите к нему и отредактируйте его:

консоль администрирования JIRA> «Задачи»  (Issues)> «Рабочие процессы» (Workflows)> «Изменить» (Edit)

Шаг 2. Добавление триггера  к переходу

Начнем с добавления триггера «Создана фиксация кода» (Commit created) к переходу «Начало прогресса» (Start progress).

Убедитесь, что вы редактируете ( а не просматриваете) рабочий процесс.

1. Выберите переход «Начальный прогресс» (Start progress) в рабочем процессе, т. е. строку «Сделать» (To Do) в «В разработке» (In Progress). Справа отобразится панель с указанием деталей перехода.

Связанная тема: Почему вы не должны настраивать триггеры для глобальных переходов

2. Нажмите «Триггеры» (Triggers ) на панели. Экран «Переход: начало прогресса» будет отображаться (View Details) на вкладке «Триггеры».

3. Нажмите «Добавить триггер» (Add trigger), затем выберите «Зафиксировать код» (Commit created), в появившемся диалоговом окне. Появится окно диагностики - вы заметите, что триггер будет добавлен для всех инструментов разработки, к которым подключен JIRA (сервер Bitbucket и FishEye / Crucible в этом примере).

 

Связанная тема: Как включить различные события для триггеров

4. Нажмите «Добавить триггер» (Add trigger), чтобы добавить триггер. Он появится в списке внизу вкладки «Триггеры». Вы можете проверить, работает ли он, нажав «Просмотреть детали» (View Details).

Это оно! Не забудьте опубликовать черновик рабочего процесса.

Шаг 3. Протестируйте триггер

Теперь, когда вы добавили триггер «Создана  фиксация кода» (Commit created) к переходу «Начало прогресса» (Start progress), давайте проверим его, сделав фиксацию.

1. Создайте задачу в проекте JIRA. Этот проект должен использовать рабочий процесс, который вы только что отредактировали.

Статус вашей новой задачи должен быть «Сделать» (To Do). Обратите внимание на ключ задачи, так как вам понадобится он для следующего шага.

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

В этом примере ключом задачи является TIS-1, на который ссылается сообщение фиксации об ошибке, показанное на скриншоте.

Связанный раздел: Ссылка на задачу JIRA в фиксации, ветви, перемещении запроса(request), или обзоре

3. Еще раз проверьте свою задачу в JIRA. Статус должен был измениться с «Сделать» (To Do) на «В разработке» (In Progress). Если вы перейдете на вкладку «История» (History) или вкладку «Активность» (Activity), вы увидите автоматический переход, который изменил статус проблемы.

Связанные темы: как пользователь сопоставляется с инструментом разработки JIRA;

Обработка событий и ограничения событий;

Как триггеры относятся к другим операциям / ограничениям рабочего процесса

Шаг 4. Добавление остальных триггеров

Теперь, когда вы добавили и протестировали триггер, выполните один и тот же процесс, чтобы добавить остальные триггеры в список выше.

Не хотите все это уладить? Хорошие новости! Вы можете загрузить аналогичный рабочий процесс (предварительно сконфигурированный с помощью триггеров) из Atlassian Marketplace: загрузите «Рабочий процесс разработки с  триггерами» (Development Workflow with Triggers).

Поздравляем! Теперь вы создали рабочий процесс с триггерами.

• Если у вас возникли проблемы с настройкой триггера или его работой, проверьте раздел «Устранение неполадок» ниже.
• Если вы хотите узнать больше о том, как работают триггеры, см. раздел «Понимание триггеров» ниже.

Понимание триггеров

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

Триггерные события  

События (например, Создана фиксация кода) становятся доступными для триггеров путем интеграции JIRA с конкретными инструментами разработки. В приведенной ниже таблице перечислены события, которые включены для каждого инструмента разработки.

 

(ИНФО) Существует известная задача, когда событие «Ветвь создана» (Branch created) не поддерживается для GitHub, который отслеживается в JSWSERVER-14473 - реализует функцию «Создать ветвь» (Create Branch) в подключаемом модуле DVCS для интеграции Github CLOSED - помните об этом при настройке триггерных событий.

Триггеры и глобальные переходы

Мы не рекомендуем настраивать триггеры для глобальных переходов, если вы не уверены, что понимаете, как триггер повлияет на поведение задачи.

Глобальный переход позволяет любому статусу в рабочем процессе перейти к определенному статусу. Это представлено в средстве просмотра рабочего процесса / редактором черным цветом  категории статуса (поле которое связывает этап выполнения задачи и статус ), указывающие на статус, на который нацелен глобальный переход. Дополнительные сведения о глобальных переходах см. в разделе «Расширенная настройка рабочего процесса».

Настройка триггеров для глобальных переходов часто может привести к неожиданному переходу на целевой статус глобального перехода. Например, подумайте над тем, настроен ли триггер «Создана фиксация кода» (Commit created) для глобального перехода к статусу «В разработке» (In Progress) . Код фиксации может происходить на многих этапах во время жизненного цикла задачи (например, для написания исходного кода, изменения кода после проверки и т. д.). Это может привести к тому, что проблема будет неправильно переходить к «В разработке» (In Progress) из ряда статусов, таких как «В обзоре» (In Review) или «Готово» (Done).

Совет. Если вы используете глобальные переходы в своем рабочем процессе, у вас, вероятно, будет несколько переходов в статус. Это означает, что у пользователей будет несколько вариантов рабочего процесса по задаче (например, как «Начало прогресса» (Start progress), так и «В разработке» (In Progress)). Чтобы скрыть опции, добавьте условие «Скрыть переход от пользователя» (Hide transition from user)к соответствующим переходам.

Ссылка на задачу JIRA в  фиксации кода, ветви, перемещения запроса(request) или просмотра

В приведенной ниже таблице описывается, как ссылаться на задачу JIRA в  фиксации кода, ветви, перемещении запроса(request) или просмотре, чтобы эти события вызывали переходы для задачи (при условии, что вы настроили триггеры на переходы).

 

Пользовательское сопоставление от инструментов разработки до JIRA

Следующий процесс описывает, как пользователь инструмента разработки сопоставляется с пользователем JIRA для триггеров рабочего процесса. Он применяется ко всем событиям, однако каждый инструмент разработки использует другой адрес электронной почты и имя пользователя для сопоставления (см. Пункт маркера после описания процесса ниже).

• Процесс: пользователь, инициирующий событие в инструменте разработки, сопоставляется с пользователем JIRA, сопоставляя адрес электронной почты, а затем имя пользователя, т. е.
  • Один пользователь JIRA с соответствующим адресом электронной почты — Перейдите к задаче как пользователь JIRA.
  • Нет пользователей JIRA с соответствующим адресом электронной почты — Перейдите к задаче как анонимный пользователь.
  • Несколько пользователей с соответствующим адресом электронной почты в JIRA — Попробуйте найти подходящее имя пользователя в этой группе пользователей. Если есть пользователь JIRA с совпадающим именем пользователя, перейдите к задаче как пользователь JIRA. Если нет совпадающего имени пользователя, перейдите к задаче как анонимный пользователь.
• Адрес электронной почты и имя пользователя, используемые для сопоставления пользователей:
  • Сервер Bitbucket

 

• FishEye / Crucible

 

• Bitbucket

• GitHub / GitHub Enterprise

 

Обработка событий и ограничения событий

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

• Обработка событий — события обрабатываются по-разному в зависимости от того, подключается ли инструмент разработки к JIRA через разъем DVCS или ссылку на приложение. Это может повлиять на то, что события задерживаются или теряются, когда JIRA недоступна:

Bitbucket и GitHub

События от Bitbucket и GitHub обрабатываются через коннектор DVCS в JIRA. Разъем DVCS обрабатывает события от Bitbucket и GitHub через два механизма синхронизации: синхронизации с помощью веб-сервисов и запланированной синхронизации.

• Синхронизация с использованием Webhook: разъем DVCS использует веб-сервисы в Bitbucket и GitHub для отправки данных в JIRA при возникновении события. Это стандартный механизм обработки событий, что означает, что задачи должны автоматически переходить почти сразу после события Bitbucket / GitHub.
• Синхронизация по расписанию: если JIRA нельзя связать, когда происходит событие Bitbucket / GitHub, событие сохраняется в коннекторе DVCS и отправляется при следующей запланированной синхронизации (каждые 60 минут, по умолчанию). Это резервный механизм в случае сбоя синхронизации с использованием веб-сервисов.

Тайник (Stash) и FishEye/Crucible

События с сервера Bitbucket и FishEye / Crucible обрабатываются по ссылке приложения. Тем не менее, Bitbucket Server и FishEye / Crucible отвечают за то, что отправляются события, и они отправляют их один раз в то время, когда происходит событие. Это означает, что если JIRA недоступна при отправке событий, события будут потеряны.

• Ограничения на события — ограничения на события накладываются на все инструменты разработки, поэтому JIRA не перегружается слишком большим количеством событий. Любые события, отправленные после превышения предела события, теряются. Пределы событий для каждого инструмента разработки перечислены ниже:

Bitbucket и GitHub

• Синхронизация с использованием Webhook: 10 ветвей; 100 коммитов
• Плановая синхронизация: 600 ветвей (интервал синхронизации в минутах x 10); 6000 фиксаций (интервал синхронизации в минутах x 100)

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

Stash

10 филиалов; 100 фиксаций за синхронизацию

Дополнительным ограничением, которое применяется в дополнение к 10 ветвям и 100  ограничениям фиксаций, является ограничение на 100 000 событий изменений задач. Например, если 100 баллов за каждую ссылку превышают 1000 ключей задачи, предел изменения задач будет превышен.

FishEye / Crucible

6000 событий на синхронизацию

Как триггеры относятся к другим операциям / ограничениям рабочего процесса

Когда переход запускается автоматически, он игнорирует любые условия, валидаторы или разрешения, настроенные для перехода.

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

Исправление проблем

Если у вас возникли проблемы с настройкой триггера или запуском триггера, выполните следующие действия для устранения неполадок.

1. Используйте диагностику триггера
2. Проверьте общие проблемы
3. Получить помощь

Используйте диагностику триггера

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

1. Перейдите к консоли администрирования JIRA> «Задачи» (Issues)> «Рабочие процессы» (Workflows)> Найдите свой рабочий процесс и нажмите «Обзор» (View (Operations) (столбец операций).

        2. В текстовом режиме (Text) (не в режиме диаграммы (Diagram)) щелкните требуемый переход.

На экране перехода (вкладка «Триггеры» (Triggers) будет отображаться), нажмите «Просмотреть детали» (View details) для нужного триггера, чтобы отобразить информацию диагностики.

• В разделе «Источники триггеров» (Trigger sources) перечислены проблемы, связанные с интеграцией между JIRA и вашими инструментами разработки. Например, настроен ли у вас правильный тип аутентификации.
• В разделе «Неудачи перехода» (Transition failures) перечислены задачи, которые не удалось автоматически перейти, несмотря на срабатывание триггера. Например, анонимный пользователь был сопоставлен с переходом, но переход имеет функцию post, для которой требуется не анонимный пользователь.

Проверьте общие проблемы

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

Я не могу добавить триггер перехода:

Возможные причины...

 

Задача не делает переход

 

Задача переходит, но не так, как ожидалось:

 

Информация, записанная для перехода, неверна:

 

Получение помощи

Если вы все еще не можете решить свою проблему, есть ряд других справочных ресурсов, включая наши форумы продуктов, ответы Atlassian Answers и нашу службу поддержки. Подробнее см. в разделе «Получение справки».

По материалам Atlassian JIRA Administrator's Guide: Configuring workflow triggers