Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
В рамках больших проектов довешивается автоматизация в виде сервисов (аналог cron'а в Linux) Jira, постфункции усложняются наличием каких-нибудь вкраплений скриптов, с более сложной логикой… например, Jython-кода (можно и Grubby, и другие языки использовать — питон здесь, кажется самым удобным), там идет напрямую взаимодействие с Jira API и \ или SOAP.
В данном случае используется Jira On-demand (по подписке от Atlassian). Большая часть таких кастомизаций там недоступна.
Если у вас есть опыт использования каких-либо таких сложных надстроек для on-demand — буду благодарен за наводку. Интересуют в первую очередь готовые продукты, позволяющие произвести эти настройки. Ибо разработка плагинов не является нашей специализацией)
Пока что я время от времени использую только Jira Command Line Interface для автоматизации простых повторяющихся задач.
Если у вас есть опыт использования каких-либо таких сложных надстроек для on-demand — буду благодарен за наводку. Интересуют в первую очередь готовые продукты, позволяющие произвести эти настройки. Ибо разработка плагинов не является нашей специализацией)
Пока что я время от времени использую только Jira Command Line Interface для автоматизации простых повторяющихся задач.
Либо специальный человек должен вручную распределять такие задачи между членами команды. И что самое неприятное — нет гарантии, что задача не будет позабыта и не застрянет в каких-то промежуточных статусах.
Не вижу решения, которое избавляет вас от человека, который назначает задачи внутри команды. Хотя судя по цитате этого следовало ожидать.
Всё равно всё падает на тимлида QA. Единственный плюс, что да, задачи не будут теряться.
По факту же вами описан базовый функционал JIRA., который и так уже многими используется.
Я тоже не вижу пока универсального решения, позволяющего освободить QA лида. Но данная функциональность всё таки покрывает значительную часть типичных ситуаций. Например, если баг не проходит тестирование, то тестировщику нет необходимости помнить, кто из разработчиков работал над этим багом. Достаточно просто переоткрыть баг, и он автоматически назначится на этого разработчика.
Безусловно, это базовый функционал Jira, однако он скорее всего будет известен только специальному человеку, отвечающему за Jira в компании. Часто в компании нет такого человека, а остальным некогда разбираться. В нашей компании этот функционал годами не использовался.
Безусловно, это базовый функционал Jira, однако он скорее всего будет известен только специальному человеку, отвечающему за Jira в компании. Часто в компании нет такого человека, а остальным некогда разбираться. В нашей компании этот функционал годами не использовался.
Достаточно простенькая схема. Вот если бы кто подсказал как делать то же самое но в рамках отдельных команд(в зависимости от значения поля), не используя разные WF для разных команд и JS…
Вам сюда.
Устанавливаете плагин JSS, разбираетесь в API Jira, пишете произвольные скрипты, вешаете их на постфункции, или выставляете в качестве сервиса. Если Jira новая есть оч. клевая jira-python либа, которая через Soap все делает — соответственно, изучаете команды которые там есть, пишете те же самые скрипты и вперед. =)
Устанавливаете плагин JSS, разбираетесь в API Jira, пишете произвольные скрипты, вешаете их на постфункции, или выставляете в качестве сервиса. Если Jira новая есть оч. клевая jira-python либа, которая через Soap все делает — соответственно, изучаете команды которые там есть, пишете те же самые скрипты и вперед. =)
Можно использовать один и тот же воркфлоу для разных команд. Пост-функции могут ссылаться не на конкретных людей, а на роли в проекте. Набор ролей должен быть одинаковым для всех проектов, использующих данный воркфлоу. А вот юзеры, назначенные на эти роли, могут отличаться. Например, в описанном выше примере в разных проектах разный QA лид.
Нет, хочется один WF, на одном проекте с разными командами(соответственно тимлидами, QA и прочее). Про роли как раз все понятно)
Вот ещё одна версия, которая без сомнения является костылём, но мало ли что)
Можете попробовать использовать conditions для transitions. Например, добавить к транзишену условие User is in a group — это позволит только юзерам из определённой группы осуществлять этот транзишен. Таким образом, вы сможете реализовать как бы несколько воркфлоу в одном — определить свой набор транзишенов для каждой группы юзеров. А уж каждому транзишену сможете назначать свои пост-функции. Это гарантированно породит вам десятиэтажную конфигурацию всего воркфлоу, но если вдруг оно окажется удобным для пользователей, то почему бы и нет)
Можете попробовать использовать conditions для transitions. Например, добавить к транзишену условие User is in a group — это позволит только юзерам из определённой группы осуществлять этот транзишен. Таким образом, вы сможете реализовать как бы несколько воркфлоу в одном — определить свой набор транзишенов для каждой группы юзеров. А уж каждому транзишену сможете назначать свои пост-функции. Это гарантированно породит вам десятиэтажную конфигурацию всего воркфлоу, но если вдруг оно окажется удобным для пользователей, то почему бы и нет)
Использовал подобную схему, и даже более развитую. Например, когда тестировщик отказывает задачу, задача должна автоматом вернуться именно на того разработчика, который ей занимался.
Но этот подход изменяет концепцию жиры. Потом возникают сложности:
1. Понять, кто делал задачу (только через историю)
2. Собрать статистку по разработчикам.
3. Поддерживать такое решение, особенно функции выбора, КАКОМУ тестировщику отдать эту работу, если он не один.
Мое мнение: для описанной задачи нужно использовать несколько проектов жиры. Например, отдельно для разработки и отдельно для тестирования. При этом можно автоматом создавать задачи в другом проекте и связывать их с исходной.
Или заводить отдельные поля тестировщик, аналитик и т.д., для каждой роли и прописывать пользователей в них.
Но этот подход изменяет концепцию жиры. Потом возникают сложности:
1. Понять, кто делал задачу (только через историю)
2. Собрать статистку по разработчикам.
3. Поддерживать такое решение, особенно функции выбора, КАКОМУ тестировщику отдать эту работу, если он не один.
Мое мнение: для описанной задачи нужно использовать несколько проектов жиры. Например, отдельно для разработки и отдельно для тестирования. При этом можно автоматом создавать задачи в другом проекте и связывать их с исходной.
Или заводить отдельные поля тестировщик, аналитик и т.д., для каждой роли и прописывать пользователей в них.
Не расскажете, как вы автоматически создавали связанные задачи в других проектах?
Можно клонировать текущую задачу в другом проекте и автоматически связывать ее при этом с помощью скрипта.
Скрипт запускается в postfunction в каком-то шаге workflow с помощью ScriptRuner
Скрипт запускается в postfunction в каком-то шаге workflow с помощью ScriptRuner
Коллеги, переассайн одной и той же задачи в процессе ее путешествия по WorkFlow это АДЪ.
Ну то есть так можно жить, если вас не интересует ничего, кроме дня сегодняшнего
Ну то есть так можно жить, если вас не интересует ничего, кроме дня сегодняшнего
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматическое назначение задач в Jira