2.x - Reuters Insider

AGILE SOFTWARE
CONFIGURATION
MANAGEMENT
ШМАРКАТЮК СЕРГЕЙ, 04-11-2010
𝑠𝑐𝑜𝑝𝑒 → ∞
2
ОБЩИЕ АСПЕКТЫ
3
ЦЕЛЬ
СВЯЗЬ МЕЖДУ:
1.
AGILE-МЕТОДОЛОГИЯМИ И
ПРАКТИКАМИ КОНФИГУРАЦИОННОГО
МЕНЕДЖМЕНТА
2.
ИНСТРУМЕНТАМИ, ИСПОЛЬЗУЮЩИХСЯ
ПРАКТИКАМИ КОНФИГУРАЦИОННОГО
МЕНЕДЖМЕНТА
4
КАКИЕ ТАКИЕ ПРАКТИКИ?
 Контроль
 Билд
версий
менеджмент
 Автоматизированные сборки
 Непрерывная интеграция
 Релиз
менеджмент
 Управление
зависимостями
5
ПОВЕСТВОВАНИЕ
ОТ ПРОСТОГО К СЛОЖНОМУ…
6
ПОВЕСТВОВАНИЕ
…С ОДНОВРЕМЕННЫМ
УСТРАНЕНИЕМ ВОЗНИКАЮЩИХ
ПРОТИВОРЕЧИЙ
7
ПРЕДСТАВЛЕНИЕ
ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ
8
ПРЕДСТАВЛЕНИЕ
ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ
9
ПРЕДСТАВЛЕНИЕ
ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ
10
ПРЕДСТАВЛЕНИЕ
ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ
11
ПРЕДСТАВЛЕНИЕ
ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ
Ветки
Релизы
Сборки
Теги
Слияния
Директории
Коммиты
12
ПОХОЖИЕ
ИДЕИ
1. Контроль версий для нескольких agile-команд:
http://www.infoq.com/articles/agile-version-control
2. Паттерны конфигрурационного менеджмента:
http://www.cmcrossroads.com/bradapp/acme/branching/
13
ПРОСТЕЙШИЙ СЦЕНАРИЙ
15
«Релиз за два дня»
ПРОСТЕЙШИЙ СЦЕНАРИЙ
 После
нескольких последовательных коммитов
разработчик желает сделать сборку
приложения
 Зачем?
1. Будем считать что сборка будет результатом
реализации функциональных требований
(баг/фича)
2. Сборка доступна конечному пользователю:



Собирается отдельное десктопное приложение
Развертывается веб-приложение
Сбор метрик и статистики (интеграционная сборка)
16
ПРОСТЕЙШИЙ СЦЕНАРИЙ
 Затем
возникает необходимость сделать
релиз
 Зачем?
 Релиз – это специальный тип сборки
 Но имеет специфичные особенности:
Полная реализация набора требований
2. Качество
3. Доступность к использованию
1.
17
ПРОСТЕЙШИЙ СЦЕНАРИЙ
ПРОСТЕЙШИЙ СЦЕНАРИЙ - ЭТО…
…СЛУЧАЙ, КОГДА ОПИСАННЫЕ ШАГИ НЕ ТРЕБУЮТ
СЛИШКОМ МНОГО УСИЛИЙ
«РЕЛИЗ ЗА ДВА ДНЯ»
18
ПРОСТЕЙШИЙ СЦЕНАРИЙ
релиз
!
1?
2?
3?
/trunk
1.0
?
1.1
?
1.2
?
19
ПРИМЕР ЧУТЬ ПОСЛОЖНЕЕ
20
Расширяем scope
ПРЕДСТАВИМ СЕБЕ …
ЧТО НУЖНО СТАБИЛИЗИРОВАТЬ РЕЛИЗ
и
ОБЕСПЕЧИТЬ ОДНОВРЕМЕННУЮ РАЗРАБОТКУ
СЛЕДУЮЩЕЙ ВЕРСИИ ПРИЛОЖЕНИЯ
21
ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА
1?
2?
3?
релиз
слияние
!
!
2.0
?
2.1
?
2.2
?
/trunk
2.3
?
/?
/1.x
22
1.0
?
1.1
?
1.2
?
ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА
ЗАМЕТИЛИ?
ВОЗНИКАЕТ НЕПОСЛЕДОВАТЕЛЬНОСТЬ В НУМЕРАЦИИ
ВЕРСИЙ!
ИМЕЕТ СМЫСЛ РАЗДЕЛИТЬ РАЗРАБОТКУ В TRUNK’E И
СТАБИЛИЗАЦИЮ РЕЛИЗА
23
ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА
/trunk
1?
2?
3?
4?
5?
6?
7?
8?
/?
/1.x
/2.x
/?
1.0
?
1.1
?
1.2
?
2.0
?
2.1
?
24
ПРИМЕР ЕЩЕ СЛОЖНЕЕ
25
Параллельное ветвление
ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА
ВАМ МОЖЕТ ПОНАДОБИТЬСЯ СТАБИЛИЗИРОВАТЬ
РЕЛИЗ В ЛЮБОЕ ВРЕМЯ
и
ПРИ ЭТОМ НЕ ПРЕРЫВАТЬ ПАРАЛЛЕЛЬНОЙ
РАЗРАБОТКИ ИЛИ СТАБИЛИЗАЦИИ РЕЛИЗА
26
ВЕТВЛЕНИЕ
ДЛЯ РЕЛИЗА
/2.x
/?
2.1
?
2.0
?
/trunk
1?
2?
3?
4?
5?
6?
0.1
0.2
0.3
0.4
0.5
0.6
1.3
?
2.2
?
/?
/1.x
1.0
?
1.1
?
1.2
?
27
ТИПЫ ВЕТОК
Время подумать о типах веток!
?
28
ТИПЫ ВЕТОК
/2.x
Ветка релиза
x.x
2.1
?
2.0
?
/trunk
x.1
1?
x.2
2?
3?
x.3
5?
x.5
4?
x.4
Ветка релиза
6?
x.6
1.3
x.7
?
2.2
x.8
?
Без типа
(просто trunk)
/1.x
1.0
?
1.1
?
1.2
?
29
ПРИМЕР ТОГО, КОГДА
ВЕТКИ НАЧИНАЮТ РАСТИ
САМИ ПО СЕБЕ
30
ТИПЫ ВЕТОК
Несовместимые изменения
/2.x
Слияние
невозможно
2.1
?
2.0
?
/trunk
x.1
1?
x.2
2?
3?
x.3
5?
x.5
4?
x.4
1.3
x.7
?
6?
x.6
2.2
x.8
?
/1.x
31
1.0
?
1.1
?
1.2
?
ТИПЫ ВЕТОК
 Несовместимость

означает то, что…
…слияние изменений не может быть
выполнено в родительскую ветку
 Пример:
Глубокий рефакторинг (изменение
иерархии директорий/файлов)
 Серьезное архитектурное/структурное
изменение
 Переписывание приложения или
его отдельных частей с нуля

32
ТИПЫ ВЕТОК
Ветка релиза
2.0
?
2.1
?
/2.x
/0.2.x
0.x.x
0.2.0 0.2.1
/trunk
x.1
1?
x.2
2?
3?
x.3
0.x.1 0.x.2 0.x.3
4?
x.4
1.3
x.5
?
0.x.4
0.x.5
Ветка релиза
/1.x
/0.1.x
1.0
?
1.1
?
Слияние
невозможно
/?
/1.x.x
1.2
?
0.1.0 0.1.1 0.1.2
Ветка
поддержки
33
ТИПЫ ВЕТОК.
ВЕТКИ ПОДДЕРЖКИ И РЕЛИЗА
/0.2.x
/0.3.x
/trunk
/1.0.x
/0.1.x
/1.x.x
Ветка релиза
34
Ветка поддержки
ТИПЫ ВЕТОК.
ВЕТКИ ПОДДЕРЖКИ И РЕЛИЗА
Ветка поддержки
Ветка релиза
Допускает слияние с
родительской веткой
 Существует до тех пор,
пока не выпущен
стабильный релиз

Не допускает слияния с
родительской веткой
 Существует всегда

Разрешены ветки-потомки
 Не разрешены веткипотомки для поддержки
 Не рекомендуются
слияния с веткамипотомками


Ветки-потомки не
разрешены
35
ТИПЫ ВЕТОК.
ЭКСПЕРИМЕНТАЛЬНЫЕ ВЕТКИ
/trunk
x.2
x.0
x.4
x.6
x.8
x.11
x.1
1?
x.3
x.5
x.7
x.9
x.10
Экспериментальная ветка
36
EXPERIMENTAL VS RELEASE
BRANCH
Ветка релиза
Не допускает ветокпотомков
 Использует строгое
именование. Пример:

Экспериментальная ветка
Допускает любое число
веток-потомков
 Правил к именованию не
выдвигается. Пример:

1.0.x
Использует
собственную область
значений для
нумерации сборок
 Рекомендуемый подход
к слияниям: после
каждой сборки/релиза

new_eng_test
Разделяет область
значений для нумерации
сборок с родственными
ветками
 Нет рекомендованного
подхода к слияниям

37
НАСЛЕДОВАНИЕ БАЗЫ
ИСХОДНОГО КОДА
/0.2.x
0.x.x
/trunk
/2.x.x
/0.1.x
/1.x.x
Последняя разработка
38
НАСЛЕДОВАНИЕ БАЗЫ
ИСХОДНОГО КОДА
Последняя разработка должна
содержаться в trunk
39
НАСЛЕДОВАНИЕ БАЗЫ
ИСХОДНОГО КОДА
/3.x.x
1.x.x
2.x.x
3.x.x
4.x.x
/trunk
/2.x.x
/1.x.x
40
ТИПЫ СБОРОК
builds
pre-alpha
(PA)
alpha (A)
beta (B)
releases
alpha
release
(AR)
beta
release
(BR)
release
candidate
(RC)
stable (ST)
41
SCM В ДЕЙСТВИИ
1.x.x
2.x.x
/trunk
PA
A
B
1.x.3
1.x.0
1.x.1
2.x.0
1.x.4
1.x.2
2.x.1
1.x.5
builds
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
42
SCRUM И SCM
/trunk
PA/A
1.x.0
1.x.1
1.x.2
1.x.3
1.0.0
1.0.1
demo
AR/BR
user stories
/1.0.x
sprint backlog
44
ИЕРАРХИЯ ДИРЕКТОРИЙ
РЕПОЗИТОРИЯ
45
ИЕРАРХИЯ ДИРЕКТОРИЙ
ПРОЕКТ
46
ИЕРАРХИЯ ДИРЕКТОРИЙ
ТЕГИ
47
ИЕРАРХИЯ ДИРЕКТОРИЙ
ВЕТКИ ПОДДЕРЖКИ
48
1.x.x
2.x.x
trunk
PA
1.x.0
1.x.3
1.x.1
A
2.x.0
1.x.4
2.x.1
/tags/builds
1.x.2
B
1.x.5
2.x.2
/branches/maintenance/versions/1.x.x
1.0.0
AR
1.0.1
BR
1.0.2
RC
1.0.3
/tags/releases
1.0.4
ST
/branches/releases/1.0.x
Номера
1
ревизий
12
39
52
73
79
93
112 126 139 140
155
170
193
201
215
230
49
Заключительное слово
Спасибо за внимание!
51