Как вы отслеживаете версии в Bugzilla?

Question

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

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

Конечным результатом является то, что поле со списком версий смешно длинно. Наконец, по разным причинам мы хотим отследить три разные версии информации: версия, в которой была обнаружена ошибка (версия), версия, в которой мы планируем исправить (веха) ошибка, и версия, в которой она была окончательно исправлена ​​(открыто для предложений). вот моя проблема на самом деле ... это может быть несколько номеров, где мы сделали ретроактивное исправление для некоторых из этих клиентов (это происходит ОЧЕНЬ часто).

Здесь мне нужна ваша коллективная мудрость:

Как вы отслеживаете эти версии (найденные, запланированные и кратные исправленные) в Bugzilla?

Каковы лучшие практики связывания версий и отслеживания ошибок?

---

Ответы

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

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

Хотя я принял ответ, я все равно приветствую ваш вклад.

Answer 1

Я искал похожую функцию в TFS, и, проводя некоторое исследование, я обнаружил, что в Bugzilla есть запрос на улучшение для управления «наблюдениями»: «Ошибка 55970 - (bz-branch) Bugzilla должна лучше работать с ветками (реализовать наблюдения)»: https://bugzilla.mozilla.org/show_bug.cgi?id=55970

Существует также предлагаемая конструкция: https://bug55970.bugzilla.mozilla.org/attachment.cgi?id=546912

Для информации, мы собираемся реализовать нечто подобное в TFS 2010 с помощью «Bug Parent» или «Bug Master» для хранения информации о самой ошибке (этапы воспроизведения, серьезность, техническая информация, затронутые компоненты ... ), который может иметь дочерний тип «Bug Child» или «Sighting», который будет содержать информацию, специфичную для данной ветви (целевой этап, приоритет, конкретную информацию для этой ветви ...).

Answer 2

Я использую Bugzilla, чтобы отслеживать не только ошибки, но и новые функции, улучшения и смутные идеи. Для каждой запланированной и выпущенной версии у меня есть отслеживающая ошибка (то, что я видел в оригинальном багзилле Mozilla и нашел полезным).

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

Если все ошибки, блокирующие исходную ошибку, закрыты / проверены (независимо от того, что реализует ваш QA), вы также можете закрыть исходную ошибку.

Answer 3

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

Что касается отслеживания версий в целом, это показалось мне разумным способом сделать что-то, учитывая, что нам, как правило, нужно поддерживать только 2-3 основные версии (плюс транк) в любое время. Если у вас есть несколько непересекающихся версий, которые требуют поддержки, например, Развертывания, ориентированные на конкретного клиента, будут усложнены. (Возможно, это вызовет головную боль в целом, и было бы лучше объединить вещи с более центральной темой версии).

Answer 4

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

Кто использует версии и как они их используют?
Как версии связаны с вехами в плане проекта?

Мы используем версию с 4 децитами (major.minor.patch.buildNO). buildNo - это номер версии SVN на момент сборки. Каждая версия хранится в JIRA, и проблемы имеют поле с версией аффекта и фиксированной версией, которое выбирается несколькими способами.

Через некоторое время у нас много версий. Джира позволяет нам контролировать список двумя способами 1. Архивные версии (выделены серым цветом из списка выбора) 2. Объединение версий (объединяет несколько версий в новую версию - без отмены)

Мы использовали Архив, но избежали слияния из-за отсутствия отмены. Таким образом, у нас все еще есть список многих версий.

Я уверен, что вы, вероятно, могли бы выполнить действие слияния в Bugzilla с некоторыми сценариями и временем, вопрос: когда можно объединить несколько более старых версий вместе?

Если я выпустил, нужно ли мне знать, что у меня 17 сборок между началом и выпуском? Нужно ли сохранять знание об ошибке, обнаруженной в сборке 1, исправленной в 2, найденной снова в 7, исправленной снова 9? Или найдено в версии 1.0.0 исправлено в версии 1.0.1 достаточно хорошо?

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

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