500 likes | 695 Vues
Agile software configuration management. Шмаркатюк Сергей , 04-11- 2010. Общие аспекты. Цель. Связь между : Agile- методологиями и практиками конфигурационного менеджмента Инструментами, использующихся практиками конфигурационного менеджмента. Какие такие практики?. Контроль версий
E N D
Agile software configuration management ШмаркатюкСергей, 04-11-2010
Цель Связь между: • Agile-методологиями и практиками конфигурационного менеджмента • Инструментами, использующихся практиками конфигурационного менеджмента
Какие такие практики? • Контроль версий • Билд менеджмент • Автоматизированные сборки • Непрерывная интеграция • Релиз менеджмент • Управление зависимостями
Повествование От простого к сложному…
Повествование …с одновременным устранением возникающих противоречий
Представление Диаграммы потока разработки
Представление Диаграммы потока разработки
Представление Диаграммы потока разработки
Представление Диаграммы потока разработки
Представление Диаграммы потока разработки Ветки Релизы Сборки Теги Слияния Директории Коммиты
Похожие идеи 1. Контроль версий для нескольких agile-команд: http://www.infoq.com/articles/agile-version-control 2. Паттерны конфигрурационного менеджмента: http://www.cmcrossroads.com/bradapp/acme/branching/
Простейший сценарий «Релиз за два дня»
Простейший сценарий • После нескольких последовательных коммитов разработчик желает сделать сборку приложения • Зачем? • Будем считать что сборка будет результатом реализации функциональных требований (баг/фича) • Сборка доступна конечному пользователю: • Собирается отдельное десктопное приложение • Развертывается веб-приложение • Сбор метрик и статистики (интеграционная сборка)
Простейший сценарий • Затем возникает необходимость сделать релиз • Зачем? • Релиз – это специальный тип сборки • Но имеет специфичные особенности: • Полная реализация набора требований • Качество • Доступность к использованию
Простейший сценарий Простейший сценарий - это… …случай, когда описанные шаги не требуют слишком много усилий «Релиз за два дня»
Простейший сценарий релиз ! /trunk ? ? 2 3 ? 1 ? ? 1.1 1.2 ? 1.0
Пример чуть посложнее Расширяем scope
Представим себе … • что нужно стабилизировать релиз • и • обеспечить одновременную разработку следующей версии приложения
Ветвление для релиза релиз слияние ! ! /trunk ? ? 2 3 ? ? 1 2.3 2.1 2.2 2.0 ? ? ? /? /1.x 1.1 1.2 1.0 ? ? ?
Ветвление для релиза Заметили? Возникает непоследовательность в нумерации версий! Имеет смысл разделить разработку в trunk’eи стабилизацию релиза
Ветвление для релиза /trunk 5 6 8 4 7 ? ? 2 3 ? 1 ? ? ? ? ? /? /1.x /? /2.x 1.1 1.2 2.1 1.0 2.0 ? ? ? ? ?
Пример еще сложнее Параллельное ветвление
Ветвление для релиза • Вам может понадобиться стабилизировать релиз в любое время • и • При этом не прерывать параллельной разработки или стабилизации релиза
Ветвление для релиза /2.x /? 2.1 2.0 ? ? /trunk 1.3 2.2 5 6 ? ? 4 ? ? 2 3 ? 1 ? ? ? 0.1 0.2 0.3 0.4 0.5 0.6 /? /1.x 1.1 1.2 1.0 ? ? ?
Типы веток Время подумать о типах веток! ?
Типы веток /2.x Веткарелиза x.x 2.1 2.0 ? ? /trunk Без типа (просто trunk) 1.3 2.2 x.8 x.7 5 6 x.2 x.5 x.6 ? ? 4 ? ? 2 3 x.1 ? 1 x.3 ? ? ? x.4 Веткарелиза /1.x 1.1 1.2 1.0 ? ? ?
Пример того, когда ветки начинают расти сами по себе
Типы веток Несовместимые изменения /2.x Слияние невозможно 2.1 2.0 ? ? /trunk 1.3 2.2 x.8 x.7 5 6 x.2 x.5 x.6 ? ? 4 ? ? 2 3 x.1 ? 1 x.3 ? ? ? x.4 /1.x 1.1 1.2 1.0 ? ? ?
Типы веток • Несовместимость означает то, что… • …слияние изменений не может быть выполнено в родительскую ветку • Пример: • Глубокий рефакторинг (изменение иерархии директорий/файлов) • Серьезное архитектурное/структурное изменение • Переписывание приложения или его отдельных частей с нуля
Типы веток /2.x Ветка релиза /0.2.x 2.1 2.0 ? ? 0.x.x 0.2.1 0.2.0 /trunk Слияние невозможно 1.3 x.5 x.2 ? 4 ? ? 2 3 x.1 ? 1 x.3 ? x.4 0.x.5 0.x.2 0.x.1 0.x.3 0.x.4 Ветка релиза /1.x.x /? /1.x /0.1.x 1.1 1.2 1.0 ? ? ? Ветка поддержки 0.1.1 0.1.2 0.1.0
Типы веток.Ветки поддержки и релиза /0.2.x /0.3.x /trunk /1.0.x /0.1.x /1.x.x Ветка релиза Ветка поддержки
Типы веток.Ветки поддержки и релиза Ветка поддержки Ветка релиза • Не допускает слияния с родительской веткой • Существует всегда • Разрешены ветки-потомки • Не разрешены ветки-потомки для поддержки • Не рекомендуются слияния с ветками- потомками • Допускает слияние с родительской веткой • Существует до тех пор, пока не выпущен стабильный релиз • Ветки-потомки не разрешены
Типы веток.Экспериментальные ветки /trunk x.2 x.0 x.4 x.6 x.8 x.11 x.7 x.9 x.3 x.1 ? 1 x.5 x.10 Экспериментальная ветка
Experimental vs release branch Ветка релиза Экспериментальная ветка • Не допускает веток-потомков • Использует строгое именование. Пример: 1.0.x • Использует собственную область значений для нумерации сборок • Рекомендуемый подход к слияниям: после каждой сборки/релиза • Допускает любое число веток-потомков • Правил к именованию не выдвигается. Пример: new_eng_test • Разделяет область значений для нумерации сборок с родственными ветками • Нет рекомендованного подхода к слияниям
Наследование базыисходного кода /0.2.x 0.x.x /trunk /2.x.x /0.1.x /1.x.x Последняя разработка
Наследование базыисходного кода Последняя разработка должна содержаться в trunk
Наследование базыисходного кода /3.x.x 1.x.x 2.x.x 3.x.x 4.x.x /trunk /2.x.x /1.x.x
SCM в действии 1.x.x 2.x.x /trunk PA 1.x.3 1.x.0 2.x.0 A 1.x.1 1.x.4 2.x.1 builds B 1.x.2 1.x.5 2.x.2 /1.x.x AR 1.0.0 BR 1.0.1 RC releases 1.0.2 1.0.3 ST 1.0.4 /1.0.x
Scrum и SCM /trunk demo PA/A AR/BR 1.0.1 1.x.0 1.x.1 1.x.2 1.0.0 1.x.3 user stories /1.0.x sprint backlog
Иерархия директорийВетки поддержки
1.x.x 2.x.x 1.x.0 1.x.3 2.x.0 1.x.1 1.x.4 2.x.1 1.x.2 1.x.5 2.x.2 /branches/maintenance/versions/1.x.x 1.0.0 1.0.1 1.0.2 1.0.3 1.0.4 /branches/releases/1.0.x Номера ревизий 1 12 39 52 73 79 93 112 126 139 140 155 170 193 201 215 230