tag:blogger.com,1999:blog-5818262524810264737.post1282313410121188176..comments2023-05-05T15:08:16.492+04:00Comments on XP Party: Работа с VCS для Agile командAnonymoushttp://www.blogger.com/profile/06524185522341241236noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-5818262524810264737.post-46074699011211119762011-04-03T01:29:04.282+04:002011-04-03T01:29:04.282+04:00Таки оставлю коммент:
>(Откройте лог репозитори...Таки оставлю коммент:<br />>(Откройте лог репозитория вашего проекта и попытайтесь найти место, где была реализована история US#96)<br /><br />В свое время я писал плагин к Trac который умеет извлекать инфу из комметов к коммиту.<br /><br />к примеру closed #1234 закрывал issue 1234 в тикет подсистиме, соответвенно тикет закрывался с комментом и ссылкой на changeset<br /><br />@ new feature in this build <br />добавлял запись в release notes который являлся обычной страницей викиВладимир Абрамовhttps://www.blogger.com/profile/06292148898347688196noreply@blogger.comtag:blogger.com,1999:blog-5818262524810264737.post-57369027718485319312011-03-16T01:39:15.934+03:002011-03-16T01:39:15.934+03:00Проглядел глазами, считаю следует почитать в ориги...Проглядел глазами, считаю следует почитать в оригинале. <br />Как показала дискуссия с Володей Абрамовым, вопрос применения этой технологии неоднозначен и заставляет задуматься вот над чем.<br />Процесс разработки непрерывен. Новые комиты происходят постоянно, инкремент продукта происходит каждый день, а может происходить и каждый час.<br /><br />Как обеспечить разработчикам простоту фиксации своего кода в репозитории и комфортное пространство для экспериментов? <br /><br />Как обеспечить тестировщикам наиболее оперативно реагировать на появление дефектов при инкременте продукта?<br /><br />В том подходе, который используется во Флексисе, trunk используют для нестабильной версии, в нем происходят инкременты и регрессии в течение итерации. Тестировщики работают с tag'ами, которые могут готовятся как в течение итерации, так и в конце итерации в зависимости от избранной политики исправления дефектов и тестирования.<br /><br />При указанном в статье подходе, важно отметить, что методология не должна нарушать простоту триал- и демо- сборок, а также простоту непрерывных комитов и "экспериментов". <br /><br />Описанный в статье подход очень просто ложится на Git/Mercurial, т.к. разработчики не имеют как таковой расшаренной экспериментальной ветки, а льют нестабильный код в свои локальные репозитории. В глобальном же репозитории лежит всегда стабильный код.<br /><br />При применении подхода, изложенного в статье, к SVN происходит следующее. В транк кладется стабильный код, а нестабильный ведется в экспериментальном бранче.<br /><br />Разработчики контролируют регрессию в эскпериментальной ветке через юнит-тесты благодаря CI (в ночных сборках).<br /><br />Тестировщики контролируют инкремент продукта в транке, в который попадает код, за который отвечают разработчики и release engineer (?). <br /><br />Что даёт такой подход? Ведь в первом и втором случае, нужно также готовить билды. И какая разница в какой ветке они хранятся?<br /><br />Вижу серьёзное преимущество. Лог комитов в транк позволит отслеживать инкремент продукта по номерам US, чего обычный подход делать не позволяет. (Откройте лог репозитория вашего проекта и попытайтесь найти место, где была реализована история US#96). Фактически мы связываем технологический процесс с организационным процессом, видим "посыл-отклик", что позволяет более удобно управлять процесом разработки в целом.<br /><br />Вывод: первый шаг к внедрению этой технологии - отмечать в комментариях к комитам номера тасков и историй, которых они касаются.Владимир Игнатьевhttps://www.blogger.com/profile/09942326249176662093noreply@blogger.com