Управление версиями для нескольких команд в корпоративных проектах
Автор: Дубовецкий Руслан
Харьков 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
ВопросыКонтакты: [email protected]
Ресурсы:• 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
Top Related