Как эффективно управлять филиалами с JIRA?

Question

Мы разрабатываем продукт, состоящий из основной среды выполнения, разделяемой между продуктами (project1, project2, ...) и частью проекта/продукта. Для каждого из этих «продуктов» мы поддерживаем несколько филиалов, потому что разные версии выкачиваются в поле и требуют обслуживания, а иногда даже поддерживают backports.

Мы также используем JIRA в качестве системы отслеживания проблем, и у меня возникли проблемы с поиском правильного способа моделирования наших типов продуктов/филиалов. Элементы JIRA, которые кажутся уместными в этом контексте являются компонентами и их версии:

• мы используем компоненты различать CORE, Pro1, PRO2 и т.д.
• мы используем компоненты также определить, какие отрасли обеспокоены
• мы использовать Fix Версия для отслеживания того, что итерации для решения этой проблемы (итеративной разработки, двухнедельные итерации)

Это более или менее работает, но с использованием компонентов типа для филиалов хак и имеет тот недостаток, что вы можете не «удалять» компоненты, только удалите их. Мы решили пойти так, потому что, если мы будем смешивать итерации вместе с ветвями в поле Fix Version, мы больше не можем запрашивать «итерацию X и ветвь Y» (JIRA не поддерживает И запросы).

Какие существуют лучшие методы для поддержки ветвей и итераций слежения в JIRA?

Некоторая статистика для контекста: мы говорим о 4 типах продуктов и о 3 основных отраслях на каждый тип продукта для поддержания.

Answer 1

Один быстрый подход, о котором я могу думать, состоит в том, чтобы ваши имена итераций включали название ветви (и, возможно, название проекта). Затем вы можете использовать версию исправления для обозначения итерации, а также ветви с именами, такими как branch1_iteration1, branch1_iteration2, branch2_iteration1 и т. Д.

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

В отличие от использования поля компонента JIRA для обозначения проекта (CORE, PRO1 и т. Д.) Вместо этого я использовал бы отдельные проекты JIRA; вы получите лучшую гранулярность и гибкость.

Answer 2

Я бы немного изменил подход к этой проблеме. Я бы установил компоненты для вашего Core Runtime и для каждой части проекта/продукта, но не делал эти компоненты ветвями конкретными. Таким образом, вы можете иметь следующие компоненты в проекте Jira:

• Ядро
• ProductX
• ProductY
• Productz

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

Эта система имеет несколько преимуществ:

1. Если проблема охватывает несколько версий/филиалов вы можете определить всех пострадавших версии в этом вопросе.
2. Вы можете установить Fix For Version в одну или несколько версий. Иногда вы можете исправить проблему только в своем багажнике или в определенной ветке. Возможно, это серьезная проблема, и вам нужно перенести исправление по веткам. Эта система дает вам возможность увидеть все это и сообщить об этом.