Сообщений в теме: 11

[Biasha]

Уважаемые коллеги!

Сейчас наша контора переходит на TFS, в связи с чем возниает множество вопросов.
Один из них такой: как настроить привязку багов к билду?
Поясню:как отделить зафикшенные баги, которые вошли в последнюю сборку от зафикшенных багов, которые еще никуда не вошли?
Требуется как-то автоматизировать процесс расстановки меток. (found in build, resolved in build).

Заранее спасибо за ответы)

[JimR]

Если у вас вопрос о том, как не посылать набилд пофиксенный баги, то проще всего не переводить их в статус build.
Если же вам нужно отличать их как-то ещё и от тех, которые непофиксены, то введите например дополнительный статус fix.

[Biasha]

Опишу проблему подробнее:
Есть билд. В нем обнаружены всякие-разные баги. Я их ловлю и заношу в ТФС как Active (New). Далее происходит исправление ошибок разработчиками - их статус меняется на Resolved.
После новой сборки я перепроверяю их. И пока я их перепроверяю, коллеги исправляют еще багов и ставят им тот же статус Resolved. Однако в моей сборке этих изменений еще нет, они появятся только в следующей!
Вопрос в том, как отличать resolved-баги уже внесенные в сборку от не внесенных. Хотелось бы автоматически приписывать все пофикшенные на момент сборки баги к этой сборке. Вопрос - как это настроить в ТФС.

[the_norn]

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

[Biasha]

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

[Tera]

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

Извините конечно, может быть я чего-то не допоняла. У нас используется TFS в качестве баг-трекинговой системы. Распределение багов и CR идет очень просто:
1. В описании багов у нас есть вкладка Details, в ней блок Build. Соответственно в нем используются поля Found in и Integrated in.
2. В описании CR так же на вкладке Details есть поле Integrated in.
Т.к. существует четкая версионность билдов, то с соотнесением багов и CR-ов по версиям, в которых они реализованы, никаких проблем нет.
Ну а для своего удобства у меня созданы специальные отчеты, чтобы можно было легко найти все решенные баги, нерешенные, все задачи которые нужно проверять в текущей версии и т.п.

[Biasha]

Вопрос был как АВТОМАТИЧЕСКИ привязывать баги к билдам. Вроде как билд прошел - и все баги, в нем зафикшенные как-то отметились, чтоб их не путать с прочими. И так для каждого билда.
В итоге сделали так: каждый найденный баг приписывается к к-л файлу или к папке. Перед билдом эти файлы с исправлениями чек-инят.
Так и осуществляется контроль.
Правда, пока это в теории. Время покажет, насколько это удобно на практике.

Если кто-то делает по другому, то рассскажите)

[JimR]

Уважаемая Biasha.

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

Поскольку TFS сильно кастомизируем, то теоретически вы (ваша компания) могли сбить эти настройки, если сильно меняли поток рабочих элементов, разные условия, поля и т.п.

Соответственно, если Вы хотите получить ответ, то я бы предложил начать сначала и описать проблему подробнее, со скриншотами и другими файлами, если это необходимо.
И выложить это описание по желанию:
1. здесь;
2. на форуме, посвященному работе с TFS;
3. в письме в техподдержку Microsoft.

[serega]

В случае, если разработчик при Check-In указывает Work Items, в ходе реализации которого было сделано изменение в коде, то при последующим билде номер данного work item попадет в отчет по сборке.

[Biasha]

Спасибо всем за ответы, действительно, все так как написал serega. Дошли до этого сами, правда)
Такой вопрос - как сделать так, что если первый билд оказался failed, чтобы work items перенеслись на следующий удачный?

[serega]

Спасибо всем за ответы, действительно, все так как написал serega. Дошли до этого сами, правда)
Такой вопрос - как сделать так, что если первый билд оказался failed, чтобы work items перенеслись на следующий удачный?

Хм..самому интересно.
Work Items действительно попадают в failed билд?

[Biasha]

Да, попадают.
Их можно и там посмотреть, в принципе, когда будет сделан работающий билд.