Как поощрить совместное использование кода и ограничить накладные расходы на отслеживание ошибок при сохранении гибкости в моих выпусках?

Question

Как вы отслеживаете изменения, тестируете ошибки, которые влияют на несколько артефактов, выпущенных отдельно?

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

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

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

---

Сценарий выпуска сплит-ошибок:

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

---

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

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

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

Я уверен, что крупномасштабные проекты от Eclipse до дистрибутивов Linux сталкивались с подобной проблемой, и мне интересно, как они ее решили (я собираюсь разобраться с ними позже).

Кто-нибудь из вас имеет опыт работы с подобной ситуацией и как вы к ней подошли?

Answer 1

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

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

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

Answer 2

Для jira используйте версии аффектов, исправленные в версиях (плюс вы можете добавить несколько пользовательских полей, как проверено QA в версиях)