По рекомендации Хенрика прочитал книгу Agile version control with multiple teams. Хотя в этой книге всего 22 страницы, но я нашёл в ней чёткое и конкретное описание правил и логики работы с системой контроля версий для Agile команд.
P.S. Спасибо Володе Абрамову, который нашёл русский перевод это книги.
P.S. Спасибо Володе Абрамову, который нашёл русский перевод это книги.
Проглядел глазами, считаю следует почитать в оригинале.
ОтветитьУдалитьКак показала дискуссия с Володей Абрамовым, вопрос применения этой технологии неоднозначен и заставляет задуматься вот над чем.
Процесс разработки непрерывен. Новые комиты происходят постоянно, инкремент продукта происходит каждый день, а может происходить и каждый час.
Как обеспечить разработчикам простоту фиксации своего кода в репозитории и комфортное пространство для экспериментов?
Как обеспечить тестировщикам наиболее оперативно реагировать на появление дефектов при инкременте продукта?
В том подходе, который используется во Флексисе, trunk используют для нестабильной версии, в нем происходят инкременты и регрессии в течение итерации. Тестировщики работают с tag'ами, которые могут готовятся как в течение итерации, так и в конце итерации в зависимости от избранной политики исправления дефектов и тестирования.
При указанном в статье подходе, важно отметить, что методология не должна нарушать простоту триал- и демо- сборок, а также простоту непрерывных комитов и "экспериментов".
Описанный в статье подход очень просто ложится на Git/Mercurial, т.к. разработчики не имеют как таковой расшаренной экспериментальной ветки, а льют нестабильный код в свои локальные репозитории. В глобальном же репозитории лежит всегда стабильный код.
При применении подхода, изложенного в статье, к SVN происходит следующее. В транк кладется стабильный код, а нестабильный ведется в экспериментальном бранче.
Разработчики контролируют регрессию в эскпериментальной ветке через юнит-тесты благодаря CI (в ночных сборках).
Тестировщики контролируют инкремент продукта в транке, в который попадает код, за который отвечают разработчики и release engineer (?).
Что даёт такой подход? Ведь в первом и втором случае, нужно также готовить билды. И какая разница в какой ветке они хранятся?
Вижу серьёзное преимущество. Лог комитов в транк позволит отслеживать инкремент продукта по номерам US, чего обычный подход делать не позволяет. (Откройте лог репозитория вашего проекта и попытайтесь найти место, где была реализована история US#96). Фактически мы связываем технологический процесс с организационным процессом, видим "посыл-отклик", что позволяет более удобно управлять процесом разработки в целом.
Вывод: первый шаг к внедрению этой технологии - отмечать в комментариях к комитам номера тасков и историй, которых они касаются.
Таки оставлю коммент:
ОтветитьУдалить>(Откройте лог репозитория вашего проекта и попытайтесь найти место, где была реализована история US#96)
В свое время я писал плагин к Trac который умеет извлекать инфу из комметов к коммиту.
к примеру closed #1234 закрывал issue 1234 в тикет подсистиме, соответвенно тикет закрывался с комментом и ссылкой на changeset
@ new feature in this build
добавлял запись в release notes который являлся обычной страницей вики