Есть ли система отслеживания ошибок/проблем, в которой проблема может быть связана с несколькими комбинациями продуктов и версий?

Question

Ищу вопрос системы слежения (Учют ошибки/очередь/projectmanagent), который может работать в следующей ситуации:

• Мы разрабатываем некоторые программы
• Это «платформы» используется для создания несколько «продукты»
• Существует «библиотека», который используется во всех продуктах
• Каждый продукт реализует множество интерфейсов из библиотеки (в сиситемах аренда путь)
• Фронтэнд отличается (модифицированный) с каждым продуктом

Довольно стандартным, я думаю, но здесь идет сложнее материал:

• проблема (ошибки, особенность, улучшение) могут применяться к нескольким продуктам
• Когда вопросы обрабатываются, они часто разрешаются только для одного продукта, полученные изменения должны быть объединены с другими продуктами позже
• Разработчики сфокусируют фокус от одного продукта до другого вполне регламентируют Rly
• Продукты развивались параллельно, но не синхронизированы
• Версионность не синхронизировано (более поздние продукты начинают с 0.0.1, содержащей все функциональные возможности, а другой продукт получил в 4.xx)
• релиз не синхронизированы , но каждый раз, когда «достаточно» вопросы будут решены, чтобы оправдать релиз
• дорожных карт могут быть различными для каждого продукта
• продуктов используют различные версии библиотеки одновременно

И, несмотря на это рабочий процесс инструмент должен дать мне и моей команды следующие идеи:

• Обзор ситуации/здоровья/состояния каждого отдельного продукта
• список изменений по всем вопросам, которые влияют на версию

Знаете ли вы, что инструмент поддерживает этот рабочий процесс?

Спасибо.

---

Дополнительная информация: Сейчас мы используем MantisBT в нашей системе отслеживания ошибок.После того, как мы попробовали «продукт-матрица» плагин [1], что сделал в основном то, что мы хотели, но не очень хорошо интегрированы, мы думали о реализации плагин для Mantis, который бы работал следующим образом:

• В настоящее время каждый выпуск имеет одну «версию», «целевую версию», «приоритет» и «статус».
• . После изменения всех этих 4 атрибутов были бы дети проблемы -производства -отношения
• Для каждой проблемы вы можете выбрать, к какому продукту он относится к
• Если продукт выбран для проблемы, вы можете указать ему версию, целевую версию, приоритет или статус
• Вы можете просмотреть только вопросы для одного из продуктов
• Вы можете создать список изменений для отдельного продукта версии комбинации

Но реализации этого кажется, что очень трудно, и мы уже думали о том, удаляясь от Mantis (слишком старый, слишком негибкий [рабочий процесс]). Я думал, что лучше всего спросить сообщество о лучших решениях нашей проблемы.

[1] http://git.mantisforge.org/w/product-matrix.git

Answer 1

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

Самая пропозициональная система была JIRA от Atlassian, так как она дает вам необходимую систему плагинов и возможности добавления такой функции, но она все равно потребует работы «специалиста по интеграции», чтобы даже выяснить, действительно есть возможно. (Источник: https://answers.atlassian.com/questions/42331/issues-with-multiple-product-version-relations + частный разговор с поддержкой JIRA по электронной почте).

Что я в итоге сделал, это установить процесс, который при разрешении билетов в Mantis разработчики создают клон билета для каждого из продуктов, над которыми они работали. Таким образом, это 1 билет все время, много билетов после, разрешая проблему, связанную с конкретными версиями продукта.

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