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

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

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

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

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

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

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

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

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

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

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

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