Работа с системой управления версиями при Agile разработке

Малышкин Фёдор (fedor.malyshkin@magnetosoft.ru)

25 апреля 2008

Страница 2

Использование SCM

История использования SCM (Software Configuration Management) , в нашей фирме, имеет очень глубокие корни, но очень простые принципы: сохраняйся и обновляйся чаще.

В большинстве случаев оно используется как: Хранилище исходных текстов и ресурсов программ Средство обмена исходными текстами (синхронизации работы)

Страница 3

Проблемы

«Нерабочие» версии проекта в репозитарии («Я тут поломал, поэтому показать не могу…»)

Конфликты при «коммите»

Страница 4

Цели презентации

Отказоустойчивость Конфликты в коде могут быть обнаружены как можно раньше Исправление маленьких проблем (возможно чаще), чем больших

(возможно реже) Всегда рабочее состояние

Даже после большой неудачной работы в репозитарии есть рабочая

копия чего-то Простота

Все члены команды используют одну и ту же схему изо дня в день, как

следствие все процедуры ясны и понятны

Страница 5

Диаграмма

Trunk = “Готово”Никакого мусора!!!

Группа #1

Группа #2

День 4День 3День 2День 1 День 5

Каждая группа имеет

свою ветку

«Сливать» из trunk

ежедневно (или чаще)

Опубликовывать работу каждый раз, когда работа

готова и проверена

Разрешать конфликты, сразу, как только они

появляются

Релиз в конце каждого спринта

0.7

Страница 6

Проблемы применения схемы

Несколько задач реализуются в ветке параллельно. Другая команда также производит публикацию в trunk.

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

Страница 7

Несколько задач реализуются в ветке параллельно. Варианты.

Не делать задач параллельно в рамках одно группы. Пытаться фокусироваться на одной задаче.

Если кто-то собирается начать параллельную работу – подождать пока предыдущая задача будет опубликована. Либо создать новую ветку для неё (если нравится жонглировать ветками).

Если кто-то начинает параллельную работу и она требует изменения существующего кода – начинайте с создания нового кода (новые классы, новые методы, новые тесты), но без модификаций существующего кода. Как только первая работа будет опубликована – можно начинать изменять код.

Страница 8

Правила

Кто бы не трогал trunk – он ответственен за работоспособность основной ветви. Включая весь предыдущий функционал!

Синхронизируйте вашу ветвь с основной периодически ( = как можно чаще)

Страница 9

Другая команда также производит публикацию в trunk. Правила.

Синхронизируйте вашу ветвь с основной ежедневно (как минимум).

Сразу разрешайте проблемы на вашей рабочей ветви. Объединяйте Вашу рабочую ветвь с основной на

периодической основе. Например по окончании задачи (разумеется нерабочий или «ломающий» код выкладывать нельзя). Не ждите окончания спринта.

Тот кто первый объединил – выиграл. В случае возникновения конфликтов при слиянии – он их исправлять уже не будет. Будет тот, кто производил слияние последним.

Страница 10

Диаграмма

Trunk = “Готово”Никакого мусора!!!

Группа #1

Группа #2

День 4День 3День 2День 1 День 5

Каждая группа имеет

свою ветку

«Сливать» из trunk

ежедневно (или чаще)

Опубликовывать работу каждый раз, когда работа

готова и проверена

Разрешать конфликты, сразу, как только они

появляются

Релиз в конце каждого спринта

0.7

Страница 11

Дополнительные возможности

Ветви версий с различным функционалом Неизменяемы версии (tags ветка)

Страница 12

Ресурсы

«Управление версиями в Subversion» - отличная книга по svn (есть в электронном виде, на русском)