вторник, 15 марта 2011 г.

Работа с VCS для Agile команд

По рекомендации Хенрика прочитал книгу Agile version control with multiple teams. Хотя в этой книге всего 22 страницы, но я нашёл в ней чёткое и конкретное описание правил и логики работы с системой контроля версий для Agile команд.

P.S. Спасибо Володе Абрамову, который нашёл русский перевод это книги.

2 комментария:

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

    Как обеспечить разработчикам простоту фиксации своего кода в репозитории и комфортное пространство для экспериментов?

    Как обеспечить тестировщикам наиболее оперативно реагировать на появление дефектов при инкременте продукта?

    В том подходе, который используется во Флексисе, trunk используют для нестабильной версии, в нем происходят инкременты и регрессии в течение итерации. Тестировщики работают с tag'ами, которые могут готовятся как в течение итерации, так и в конце итерации в зависимости от избранной политики исправления дефектов и тестирования.

    При указанном в статье подходе, важно отметить, что методология не должна нарушать простоту триал- и демо- сборок, а также простоту непрерывных комитов и "экспериментов".

    Описанный в статье подход очень просто ложится на Git/Mercurial, т.к. разработчики не имеют как таковой расшаренной экспериментальной ветки, а льют нестабильный код в свои локальные репозитории. В глобальном же репозитории лежит всегда стабильный код.

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

    Разработчики контролируют регрессию в эскпериментальной ветке через юнит-тесты благодаря CI (в ночных сборках).

    Тестировщики контролируют инкремент продукта в транке, в который попадает код, за который отвечают разработчики и release engineer (?).

    Что даёт такой подход? Ведь в первом и втором случае, нужно также готовить билды. И какая разница в какой ветке они хранятся?

    Вижу серьёзное преимущество. Лог комитов в транк позволит отслеживать инкремент продукта по номерам US, чего обычный подход делать не позволяет. (Откройте лог репозитория вашего проекта и попытайтесь найти место, где была реализована история US#96). Фактически мы связываем технологический процесс с организационным процессом, видим "посыл-отклик", что позволяет более удобно управлять процесом разработки в целом.

    Вывод: первый шаг к внедрению этой технологии - отмечать в комментариях к комитам номера тасков и историй, которых они касаются.

    ОтветитьУдалить
  2. Таки оставлю коммент:
    >(Откройте лог репозитория вашего проекта и попытайтесь найти место, где была реализована история US#96)

    В свое время я писал плагин к Trac который умеет извлекать инфу из комметов к коммиту.

    к примеру closed #1234 закрывал issue 1234 в тикет подсистиме, соответвенно тикет закрывался с комментом и ссылкой на changeset

    @ new feature in this build
    добавлял запись в release notes который являлся обычной страницей вики

    ОтветитьУдалить