-Музыка

 -Поиск по дневнику

Поиск сообщений в Кузнец_Ранеток

 -Подписка по e-mail

 

 -Сообщества

Читатель сообществ (Всего в списке: 1) kayros

 -Статистика

Статистика LiveInternet.ru: показано количество хитов и посетителей
Создан: 08.10.2007
Записей: 752
Комментариев: 891
Написано: 2203


Тикет

Понедельник, 04 Октября 2010 г. 02:15 + в цитатник
По поводу "каждому изменению в репозитарии соответствует свой тикет" - у нас вполне выдерживается такая методика.

1) Теоретически, при коммите может срабатывать hook, которые проверят наличие указанной баги в багтрекере и даже то, что handler-ом этой баги является тот самый разработчик, который commit-ит код. Сам такое писал, но реально использовать не пришлось - вполне помогает фраза "просто надо так делать".
2) Если коммит относится к нескольким связанным багам, то указываем их все. Соответственно в багтрекере для каждой из багов будет выведен список измененных файлов и список связаных багов.

Вообще связь commit-ов с багами - штука очень полезная, т.к. позволяет:
1) По строчке исходника получить номер ревизии (svn annotate), а по номеру ревизии - к какой баге это относится. Очень помогает при ответе на вопрос "кто и зачем это сделал".
2) Многие исправления разработчиков можно заворачивать назад вообще не тестируя, т.к. по diff-у видно что поменяли не все файлы, забыли перенести правки из trunk в branch и т.п.
3) Если в багтрекере можно учитывать время, то сразу понятно как соотносится время работы над задачей с объемом изменений.

 

Добавить комментарий:
Текст комментария: смайлики

Проверка орфографии: (найти ошибки)

Прикрепить картинку:

 Переводить URL в ссылку
 Подписаться на комментарии
 Подписать картинку