JIRA: как я могу делиться модулями между проектами? - PullRequest
2 голосов
/ 18 октября 2011

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

Компоненты JIRAнедостаточно для моих нужд, так как разработчик модуля или библиотеки не может соотнести проблемы, возникающие в разных проектах для своего модуля, и назначить их разным версиям.Мне нужна иерархия проектов, где компонент в проекте более высокого уровня (продукта) относится к другому проекту более низкого уровня (модуля).

Кажется, Atlassian не хочет (не может?) Добавлять такиеособенность JIRA, несмотря на многочисленные проблемы, связанные с девятилетним прошлым.Переход к другому программному обеспечению для отслеживания проблем, имеющему эту функцию (если таковая существует), в настоящее время для нас невозможен.

Судя по количеству ответов по связанным вопросам в системе JIRA Atlassian, мы можемЭто не единственная компания с этой проблемой, поэтому я хотел бы знать, что другие люди делают, чтобы обойти ее.

Мой текущий план состоит в том, чтобы использовать компоненты для проектов продуктов, а также автоматически создавать и связывать клоны.проблем с компонентами в соответствующем модуле / проекте библиотеки.Клоны неоптимальны, поскольку они не так сильно связаны с оригиналом, как мне бы хотелось, и они удваивают количество проблем в системе (или больше, если проблема в модульном проекте должна дублироваться в других более высоких проектахСкажем, если исправление сломало бы API или это была критическая проблема, о которой должен быть предупрежден любой пользователь библиотеки), но я бы хотел сохранить оригинал, так как после исправления в модуле и закрытия модуляпроблема, было бы больше времени, необходимого для интеграции фиксированного модуля в продукт.

Я обнаружил плагины, которые позволяют выполнять пост-функции при переходах, например, «Утилиты CustomWare JIRA», так что они должны работать для автоматического клонирования., связывание и обновление, хотя я не уверен на 100%.

Чего не хватает, тем не менее, это хороший способ управления зависимостями между различными версиями продуктов и модулей (т. Е. Версия XY продукта A использует версию IJ библиотеки B), поскольку компоненты с поддержкой версий - это другое делочто JIRA не делает.

Есть идеи получше?

Ответы [ 3 ]

1 голос
/ 19 октября 2011

Я бы относился к повторно используемым компонентам так же, как они относятся к распространению (например, к DLL), как к отдельным проектам в Jira.

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

Это не поможет поддерживать межпроектное сопоставление (т. Е. Системе A v1.3 требуется компонент B v2.7), но она становится достаточно простой для размещения в вики.

0 голосов
/ 29 декабря 2011

OnTime использует древовидную структуру для проектов, что позволяет открывать фильтр для просмотра потомков, как если бы они были в текущей ветви.Я не знаю, поможет ли это вам.

0 голосов
/ 25 октября 2011

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

~ Matt

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...