LecturesCMC/ProgAdm2011/04_Security_IssueTracking

Баги и фичи как важный аспект процесса разработки

• Если проект является чем-то более сложным, чем "Hello, world", то он имеет нетривиальную структуру. И, как следствие, выполняется целиком не за один сеанс программирования.
  • А даже если и за один, если код не выкидывается, его приходится дописывать и исправлять.
• В процессе работы надо кодом возникает разное:
  • В различные моменты времени по тем или иным причинам принимается решения вбить костыль, а не "делать нормально"
  • В процессе умозрительного созерцания кода какая-то проблема отмечается, но её исправление по тем или иным причинам откладывается
  • Приходит пользователь (другой разработчик) и начинает рассказывать, как всё не работает
  • Возникает идея сделать какое-то место лучше, гибче и быстрее
  • Прибегает начальник/пользователь/разработчик с криками "позарез нужна эта фича"
  • Нужно мрачно перебрать код и сделать с ним что-то нетривиальное
• Всё это (и многое другое, что лздесь не перечислено), вследствие большого своего количества, неплохо бы фиксировать. Но, кроме того, это нужно ещё и исправлять. Кому-то. Когда-то.
  • На самом деле, примерно здесь же возникает задача управления процессом проведения всех этих доработок (распределение того, кто, когда и в каком объёме), но, как отмечалась ранее, в рамках данного курса она не ялвяется основной
• Собственно весь процесс разработки можно представить как череду доработок различной степени величины, которые ведут к определённой цели.
• Каждой подобной доработке можно сопоставить нечто, фиксирующее её судьбу: описание изменения, то, кто ей занимается, историю обсуждения, прогресс выполнения. Это документальное отображение и есть "тикет".
  • Заметим, что, поскольку доработка может находиться в том или ином состояни (к ней ещё не приступали, в работе, отложена, тестируется, завершена, отклонена), то эти состояния естественно формалиховать и отображать в упомянутом тикете.
• Как уже было сказано, все изменения делаются большей частью не просто так. у них есть цель. Для обозначения цели, заради которой делается данная наработка, будем использовать термин "miletone".
  • Как можно догадаться по термину, цель вовсе не обязательно должна быть единственной. Более того, она естественным образом может претерпевать изменения во времени и фиксирование её представляет собой некое организационное упражнение.
  • Помимо milestone, существует понятие релиза (версии). Структурно, версии так же, как и milestone, связаны с набором тикетов; семантически, релизы более жёстко привязаны к времени, нежели milestone (например, может быть milestone "покрыть тестами весь код" или "перейти на event-oriented модель")
• Таким образом, получаем, что с целью связан набор доработок и для достижения цели необходимым и достаточным условием является выполнение всех доработок, с ней связанных.

Как можно организовать bugtracking только на VCS

• Комментарии специального вида
• Хуки для их парсинга
  • Статистика
  • Не пускать увеличение FIXME перед релизом
• В чём польза
  • Всё доступно по месту (в том числе история!)

Trac

• Примером веб-приложения, которое позволяет организовать project management, является trac. Его плюшки:
  • Он на python
  • У него есть базовая интеграция с репозиторием и вики
  • Он простой и модульный
• Возможности trac'а: ведение тикетов — создание/изменение/дополнение (почему удаление плохо), просмотр репозитория, вики
• В сторону: про то, какой packaging у python-приложений и как он соотносится с packaging в OS
  • Python - интерпретируемый, поэтому обычно для работы достаточно скачать тарболл и запустить там чудо-файлик (bootstrap)
  • В то же время, у python есть своя пакетная инфраструктура — eggs + pip/easy_install
  • Кроме того, пакетная инфраструктура есть и у любого уважающего себя дистрибутива
  • Как следствие, возникает вопрос: как и откуда ставить? Ответ на него не так очевиден.
• Объектная модель в trac
  • Понятие проекта
  • Параметры тикетов: priority, severity, component, owner/reporter
• Плагины
  • Могут устанавливаться как глобально, так и в рамках проекта

Приятные свойства

• Одни доработки зависят от других, и эту зависимость можно выражать, указывая её в тикетах
  • Виды зависимостей бывают разные
  • Вместо одного тикета, который зависит от полусотни, возможно, имеет смысл завести milestone
• Зачатки time- и resource- менеджмента
  • Диаграммы Гантта
• Связывание тикетов с репозиторием
  • Комментарии в тикетах из коммитмессаджей
  • Закрытие тикетов коммитами
  • Обратно — просмотр списка коммитов, где упоминается данный тикет
• Оповещение
  • Как и когда оповещать?
  • Возможные схемы оповещения
• Вики

Основные выводы

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

Ссылки

• Trac: http://trac.edgewall.org/wiki/TracGuide

• Redmine: http://www.redmine.org/projects/redmine/wiki/Guide