Работа с системой управления версиями при Agile разработке Малышкин Фёдор (fedor.malyshkin@magnetosoft.ru)fedor.malyshkin@magnetosoft.ru 25 апреля 2008. - презентация

1 Работа с системой управления версиями при Agile разработке Малышкин Фёдор 25 апреля 2008

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

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

4 Страница 4 Цели презентации Отказоустойчивость Конфликты в коде могут быть обнаружены как можно раньше Исправление маленьких проблем (возможно чаще), чем больших (возможно реже) Всегда рабочее состояние Даже после большой неудачной работы в репозитарии есть рабочая копия чего-то Простота Все члены команды используют одну и ту же схему изо дня в день, как следствие все процедуры ясны и понятны

5 Страница 5 Диаграмма

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

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

8 Страница 8 Правила Кто бы не трогал trunk – он ответственен за работоспособность основной ветви. Включая весь предыдущий функционал! Синхронизируйте вашу ветвь с основной периодически ( = как можно чаще)

9 Страница 9 Другая команда также производит публикацию в trunk. Правила. Синхронизируйте вашу ветвь с основной ежедневно (как минимум). Сразу разрешайте проблемы на вашей рабочей ветви. Объединяйте Вашу рабочую ветвь с основной на периодической основе. Например по окончании задачи (разумеется нерабочий или «ломающий» код выкладывать нельзя). Не ждите окончания спринта. Тот кто первый объединил – выиграл. В случае возникновения конфликтов при слиянии – он их исправлять уже не будет. Будет тот, кто производил слияние последним.

10 Страница 10 Диаграмма

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

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