Embedded Files
Вот трудности, с которыми столкнулся лично я на своей шкуре.
Проблема: кривые комментарии
пустые комментарии;
Решение:
- матом и c поздатыльниками, НИКОГДА больше так не делай, комент к коммиту должен конкретно описывать что ты делаешь.
минималистические комменты типа fix #XXX, close #xxx
Решение:
- обязательный коммент, с КРАТКИМ описанием фиксированных багов, одна из мотиваций - ГЕНЕРАЦИЯ changelog'а автоматом.
Проблема: боязнь работать с РАБОЧЕЙ копией (working copy), это когда девелопер делает checkout, а потом реально работает с "папочкой рядом" и "аккуратненько" копирует в working copy перед коммитом "нужные файлы".
Решение:
- матом и c КРОВАВЫМИ пиздюлями, НИКОГДА больше так не делай, РАБОТАЕШЬ с системой контроля версий?? правь исходники в РАБОЧЕЙ КОПИИ РЕПОЗИТОРИЯ
мотивации: при копировании часто проебываются файлы (см. следующая проблема)... еще тут есть моменты, когда часть ветки это компонент типа "удаленный", но это решается развертыванием всех компонентов системы на машине разработчика, либо скриптами быстрой выкладки удаленного компонента в тестовое окружение (девелоперский сервак)
Проблема: ой, я забыл закомитить этот файлик...
Решение:
- одно 100% верное, но подлое, поймать какой нибудь failed build, после этого молча зайти на машину разработчика и перенести "незакомиченный файл" к себе, а потом выгнать его в сверхурочные переписывать с нуля этот проебанный файлик с дедлайном СУТКИ.
Проблема: ой, а тут у меня конфликт, а как его разруливать?
Решение:
- тут надо только на пальцах объяснять, показывать как работать с Araxis Merge и подобных утилитах, т.е. садишься рядом и конкретно фиксишь конфликт, чтобы разработчик понял что к чему ну и еще когда человек немного натаскается, доверить ему тестово промержевать какой нибудь бранч в транк ветку.
Проблема: погоди, я еще не закомитил, не довел до логического конца...
Решение:
- решения разумного нет, ДА это отмазки, и причины могут быть разные, но в 80% случаев, нифига не конструктивные, а банальное раздолбайство, но тут надо выбирать что лучше коммит вопреки желанию разработчика с пометкой "оно не рабочее я низачто не отвечаю", либо коммит, за который разработчик отвечает хотя бы морально.
Теперь, что касается Trac.
Он народу нравится, НО без множества ньюансов как и любой другой багтрекинг, работать не будет.
Проблема: для чего ОН нужен?
- IMHO... Trac это действительно ОТРАЖЕНИЕ текущего состояния разработки, если чего то нет в Trac (нет коммита в репозиторий, или нет тикета, или нет документации в Wiki) значит этого НЕТ вообще, даже если об этом говориться постоянно на словах и на совещаниях у себя в команде я ввел пару правил, которые наиболее строго отношу именно к себе.
Решение:
1. НЕ ДОБАВИЛ ТИКЕТ?
- нечего долбать разработчиков: о том что он чего то не сделал.
2. НЕ ЗАДОКУМЕНТИРОВАЛ в Wiki изменение протокола/требований/прототипов формы?
- нечего долбать разработчиков: типа "а я вот об этом же говорил?".
3. НЕТ КОМИТА В РЕПОЗИТОРИЙ?
- Можно долбить разработчиков и склонять на все лады, о том что они ничего не делают, даже если они из IDE не вылезают :-)
Исходя из этих правил возникают все нижеследующие проблемы:
Проблема: Детальность описания задачи (именно task, а не bug, с багами как то проще)
Решение:
- Если задача БОЛЬШАЯ и состоит из множества пунктов разбивайте на отдельные задачи, к сожалению в trac'е список тикетов ЛИНЕЙНЫЙ и нельзя сделать одну большую задачу а в ней ставить подзадачки, разруливать можно через "короткие майлстоуны", но обычно майлстоун привязан к итерации (итерация большая - Месяц), поэтому такая штука как "иерархические задачи", было бы очень круто сделать, но пока пытаюсь разрулить либо через обычный UL/LI внутри задачи, либо одна большая задача в ней краткое описание и внутри ссылки на более маленькие через #XXX
Проблема: ой, а я не видел что ты мне задачу поставил/изменил...
Решение:
- email рассылка изменений, работает, но с трудом... наилучшее решение в наших условиях это ДВА отчета (созданных на основе стандартных) и подписка на них по RSS
Отчет номер 1.
Report Title: Мои задачи
Description: Список задач которые не завершены и связаны со мной (задачи сгрупированы по статусу и размечены цветом).
===
SELECT p.value AS __color__, status AS __group__, id AS ticket, summary, component, version, milestone, t.type AS type, priority, time AS created, t.status AS status, changetime AS _changetime, description AS _description, reporter AS _reporter, owner, status FROM ticket t LEFT JOIN enum p ON p.name = t.status AND p.type = 'status' WHERE t.status <> 'closed' AND owner LIKE '%$USER%' ORDER BY status, id
===
Отчет номер 2.
Report Title: Текущие задачи
Description: Список всех тикетов активных с разбивкой по статусам и показыванием custom полей "планируемая дата начала" и "планируемая дата завершения".
===
SELECT p.value AS __color__, status AS __group__, t.id AS ticket, summary, component, version, milestone, t.type AS type, owner, time AS created, changetime AS _changetime, description AS _description, reporter AS _reporter, t_due_assign.value AS due_assign, t_due_close.value AS due_close FROM ticket t LEFT OUTER JOIN ticket_custom AS t_due_assign ON (t.id = t_due_assign.ticket AND t_due_assign.name = 'due_assign') LEFT OUTER JOIN ticket_custom AS t_due_close ON (t.id = t_due_close.ticket AND t_due_close.name = 'due_close') LEFT JOIN enum p ON p.name = t.status AND p.type = 'status' WHERE status <> 'closed' ORDER BY t.status, t.id, milestone, t.type, time
===
Проблема: я пофиксил, тикет закрыл, а ты че не потестил?
Решение:
- ставим trac и ставим к нему http://trac-hacks.org/wiki/TestingWorkflow
Проблема: а у нас тут куча проектов, как в них тикеты отслеживать?
Решение:
- для поиска используем http://trac-hacks.org/wiki/SearchAllPlugin
- для мониторинга тикетов RSS+Email
Проблема: а как тикет закрыть/пофиксить/перевести в тестинг?
Решение:
- hooks/post-commit-hook для svn.
Короче, Trac мне понравился во многих моментах больше чем Джира, Мантисс, Багзилла или Eventum вместе взятые, IMHO потому что при правильном умении, он БОЛЬШЕ чем баг трекер. :-)
Google Sites
Report abuse