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

Question

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

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

• мы используем компоненты, чтобы различать CORE, PRO1, PRO2 и т. Д.
• мы используем компоненты также, чтобы определить, какие ветви имеют отношение
• мы используем Fix Version, чтобы отслеживать, какая итерация решает проблему (итеративная разработка, двухнедельные итерации)

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

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

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

Answer 1

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

• Core
• ProductX
• ProductY
• Productz

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

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

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

Answer 2

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

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

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