Управление версиями для нескольких команд в корпоративных проектах

Автор: Дубовецкий Руслан

Харьков 2014 Artezio

Проблемы

• Конфликты при «коммите»• Затирание чужих изменений• Остановка корректной работы команды при нерабочем коде в

ветках• Проблема согласования версий модулей и компонентов в ветках• Сложная структура веток• Ненужные ветки• Дублирование веток

Харьков 2014 Artezio

Цель• Быстрое информирование об ошибках • Конфликты кода и проблемы интеграции должны обнаруживаться как

можно раньше. • Лучше исправлять небольшие ошибки часто, чем большие проблемы

редко.

• Постоянная готовность к поставке • Даже после действительно плохой итерации должно быть хоть что-то, что

можно выпустить.

• Простота • Все члены команды будут ежедневно использовать эту схему, поэтому

правила должны быть простыми и понятными.

Харьков 2014 Artezio

Концепция шаблона управления версиями

Для эффективного управления версиями ПО, стоит разделить проект на ветки по командам(есть еще по модулям):

• Главная ветка Trunk(код всегда готов к релизу).• Рабочие ветки команд.• Ветки релизов.

Харьков 2014 Artezio

// Правило: Каждая ветвь (даже основной ствол, т.е. trunk) имеет владельца и политику

Главная ветка Trunk

Готово к поставке - означает, что интеграционные, модульные тесты пройдены и код не блокирует, уже работающую, функциональность

Харьков 2014 Artezio

// Правило: Не совмещайте несколько циклов разработки в одной ветве

Публикация из рабочей ветки в Trunk

Харьков 2014 Artezio

// Рекомендация: Создавайте новую ветвь только тогда, когда вы хотите залить код в систему контроля версий , и не существует ветви, которую можно для этого использовать, не нарушив ее политику

При публикация в trunk идет полная синхронизация двух веток.

Проблемы синхронизации с Trunk

1. Что если наша команда параллельно реализует несколько задач? 2. Что если другие команды тоже делают публикацию в trunk?

Харьков 2014 Artezio

Возможные решения параллельной разработки в

команде • Не разрабатывать параллельно. Постараться сфокусировать работу

всей команды на одной задаче. • В командной ветке может находиться только одно не готовое задание.

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

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

Харьков 2014 Artezio

// Правило: Тот кто вносит изменения в trunk отвечает за то, что он остается готовым к поставке, включая всю предыдущую функциональность!

// Правило: Постоянно синхронизируйте ваш код с рабочей ветвью (так часто, как это возможно)

Правила работы в командной ветке• Тот кто работает над самой приоритетной задачей – Король, или ведущий разработчик. • Все остальные в команде – Слуги, или просто разработчики. • Вы хотите быть Королем. Постарайтесь найти способ принять участие в работе над

самой приоритетной задачей. • Когда Королю нужна помощь, Слуги немедленно предлагают ему свои услуги. • Слуга не может мешать Королю. • Слуга не может заливать в рабочую ветвь код, не готовый к поставке. Король может

заливать в ветку команды все, что он хочет. • Как только готова самая приоритетная задача, Королем становится тот, кто реализует

следующую по приоритетности задачу.

Харьков 2014 Artezio

Подхват изменений из trunk

День в команде начинается с того, что выбранный член команды должен подхватывать изменения из trunk в рабочую ветку команды. Любые конфликты версий считаются первостепенными задачами.

Харьков 2014 Artezio

// Правило: Сливайте код из trunk-а в вашу рабочую ветвь каждый день

// Правило: Решайте конфликты в ветви, которая менее стабильна

Одновременная синхронизация с trunk

// Правило: Заливайте код из вашей рабочей ветви в trunk на регулярной основе, например, каждый раз, когда готово задание. Не ждите до конца итерации!

// Побочный эффект: Побеждает тот, кто первым заливает код в trunk!

Харьков 2014 Artezio

Ветви релизов

Харьков 2014 Artezio

// Правило: Сливайте код в trunk по иерархии создания веток

Общая картина

Харьков 2014 Artezio

// Правило: Делаем слияние сверху вниз, копируем снизу вверх

// Правило: Всегда принимайте стабилизирующие изменения. Никогда не навязывайте дестабилизирующие изменения

Subversion механизмы для реализации шаблона управления версиями

Харьков 2014 Artezio

Mercurial децентрализованное управление версиями

Харьков 2014 Artezio

GIT реализация шаблона управлени

я версиями

Харьков 2014 Artezio

ВопросыКонтакты: andrus.god@gmail.com

Ресурсы:• http://www.infoq.com/articles/agile-version-control• http://agilerussia.ru/practices/version-control-with-multiple-teams/• http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenc

hes-rus-final.pdf• http://nvie.com/posts/a-successful-git-branching-model/• http://habrahabr.ru/post/106912/• http://hginit.com/• http://1drv.ms/NaYdpD

Харьков 2014 Artezio