AGILE SOFTWARE CONFIGURATION

MANAGEMENT

ШМАРКАТЮК СЕРГЕЙ, 04-11-2010

2

𝑠𝑐𝑜𝑝𝑒→∞

3

ОБЩИЕ АСПЕКТЫ

4

ЦЕЛЬ

СВЯЗЬ МЕЖДУ:

1. AGILE-МЕТОДОЛОГИЯМИ И ПРАКТИКАМИ КОНФИГУРАЦИОННОГО МЕНЕДЖМЕНТА

2. ИНСТРУМЕНТАМИ, ИСПОЛЬЗУЮЩИХСЯ ПРАКТИКАМИ КОНФИГУРАЦИОННОГО МЕНЕДЖМЕНТА

5

КАКИЕ ТАКИЕ ПРАКТИКИ?

Контроль версий

Билд менеджмент Автоматизированные сборкиНепрерывная интеграция

Релиз менеджмент

Управление зависимостями

6

ПОВЕСТВОВАНИЕ

ОТ ПРОСТОГО К СЛОЖНОМУ…

7

ПОВЕСТВОВАНИЕ

…С ОДНОВРЕМЕННЫМ УСТРАНЕНИЕМ

ВОЗНИКАЮЩИХ ПРОТИВОРЕЧИЙ

8

ПРЕДСТАВЛЕНИЕ

ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ

9

ПРЕДСТАВЛЕНИЕ

ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ

10

ПРЕДСТАВЛЕНИЕ

ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ

11

ПРЕДСТАВЛЕНИЕ

ДИАГРАММЫ ПОТОКА РАЗРАБОТКИ

12

ПРЕДСТАВЛЕНИЕ

ДИАГРАММЫ ПОТОКА РАЗРАБОТКИВетки

Релизы

Сборки

Теги

Слияния

Директории

Коммиты

13

ПОХОЖИЕ ИДЕИ

http://www.cmcrossroads.com/bradapp/acme/branching/

2. Паттерны конфигрурационного менеджмента:

http://www.infoq.com/articles/agile-version-control

1. Контроль версий для нескольких agile-команд:

15

ПРОСТЕЙШИЙ СЦЕНАРИЙ«Релиз за два дня»

16

ПРОСТЕЙШИЙ СЦЕНАРИЙ

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

Зачем?1. Будем считать что сборка будет

результатом реализации функциональных требований (баг/фича)

2. Сборка доступна конечному пользователю: Собирается отдельное десктопное приложение Развертывается веб-приложение Сбор метрик и статистики (интеграционная

сборка)

17

ПРОСТЕЙШИЙ СЦЕНАРИЙ

Затем возникает необходимость сделать релиз

Зачем? Релиз – это специальный тип сборки Но имеет специфичные особенности:

1. Полная реализация набора требований2. Качество3. Доступность к использованию

18

ПРОСТЕЙШИЙ СЦЕНАРИЙ

ПРОСТЕЙШИЙ СЦЕНАРИЙ - ЭТО……СЛУЧАЙ, КОГДА ОПИСАННЫЕ ШАГИ НЕ

ТРЕБУЮТ СЛИШКОМ МНОГО УСИЛИЙ

«РЕЛИЗ ЗА ДВА ДНЯ»

19

ПРОСТЕЙШИЙ СЦЕНАРИЙ

? ? ?

!релиз

/trunk

1 2 3 ? ? ?1.0 1.1 1.2

20

ПРИМЕР ЧУТЬ ПОСЛОЖНЕЕРасширяем scope

21

ПРЕДСТАВИМ СЕБЕ …

ЧТО НУЖНО СТАБИЛИЗИРОВАТЬ РЕЛИЗ

и

ОБЕСПЕЧИТЬ ОДНОВРЕМЕННУЮ РАЗРАБОТКУ СЛЕДУЮЩЕЙ ВЕРСИИ

ПРИЛОЖЕНИЯ

22

?

ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА

? ? ?

!релиз

/trunk

1 2 3

? ? ?1.0 1.1 1.2

!слияние

/?

? ? ?2.0 2.1

/1.x

2.32.2

23

ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА

ЗАМЕТИЛИ?

ВОЗНИКАЕТ НЕПОСЛЕДОВАТЕЛЬНОСТЬ В НУМЕРАЦИИ ВЕРСИЙ!

ИМЕЕТ СМЫСЛ РАЗДЕЛИТЬ РАЗРАБОТКУ В TRUNK’E И СТАБИЛИЗАЦИЮ РЕЛИЗА

24

ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

/?

? ? ?4 5

/1.x

6

? ?2.0 2.1

? ?7 8

/?/2.x

25

ПРИМЕР ЕЩЕ СЛОЖНЕЕПараллельное ветвление

26

ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА

ВАМ МОЖЕТ ПОНАДОБИТЬСЯ СТАБИЛИЗИРОВАТЬ РЕЛИЗ В ЛЮБОЕ

ВРЕМЯ

и

ПРИ ЭТОМ НЕ ПРЕРЫВАТЬ ПАРАЛЛЕЛЬНОЙ РАЗРАБОТКИ ИЛИ

СТАБИЛИЗАЦИИ РЕЛИЗА

27

ВЕТВЛЕНИЕ ДЛЯ РЕЛИЗА

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

/?

? ? ?4 5

/1.x

6

? ?2.0 2.1

/?/2.x

? ?1.3 2.2

0.1 0.2 0.3 0.4 0.5 0.6

28

ТИПЫ ВЕТОК

Время подумать о типах веток!

?

29

ТИПЫ ВЕТОК

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

? ? ?4 5 6

? ?2.0 2.1

? ?1.3 2.2

/1.x

/2.xВетка релиза

Ветка релиза

Без типа(просто trunk)

x.x

x.1 x.2 x.3 x.4 x.5 x.6 x.7 x.8

30

ПРИМЕР ТОГО, КОГДА ВЕТКИ НАЧИНАЮТ РАСТИ САМИ ПО СЕБЕ

31

ТИПЫ ВЕТОК

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

? ? ?4 5 6

? ?2.0 2.1

? ?1.3 2.2

/1.x

/2.x

x.1 x.2 x.3 x.4 x.5 x.6 x.7 x.8

Несовместимые изменения

Слияние невозможно

32

ТИПЫ ВЕТОК

Несовместимость означает то, что……слияние изменений не может быть

выполнено в родительскую веткуПример:

Глубокий рефакторинг (изменение иерархии директорий/файлов)

Серьезное архитектурное/структурное изменение

Переписывание приложения или его отдельных частей с нуля

33

ТИПЫ ВЕТОК

? ? ?

/trunk

1 2 3

? ? ?1.0 1.1 1.2

?4

? ?2.0 2.1

?1.3

/1.x

/2.x

x.1 x.2 x.3 x.4 x.5

/?

Слияние невозможно

/1.x.x

0.x.x

Ветка релиза

Ветка релиза

Ветка поддержки

0.x.1 0.x.2 0.x.3 0.x.4 0.x.5

/0.1.x

/0.2.x

0.1.0 0.1.1 0.1.2

0.2.0 0.2.1

34

ТИПЫ ВЕТОК.ВЕТКИ ПОДДЕРЖКИ И РЕЛИЗА

/trunk

/0.1.x

/0.2.x

/1.x.x

/0.3.x

/1.0.x

Ветка поддержки

Ветка релиза

35

ТИПЫ ВЕТОК.ВЕТКИ ПОДДЕРЖКИ И РЕЛИЗА

Не допускает слияния с родительской веткой

Существует всегда

Разрешены ветки-потомки Не разрешены ветки-

потомки для поддержки Не рекомендуются

слияния с ветками- потомками

Допускает слияние с родительской веткой

Существует до тех пор, пока не выпущен стабильный релиз

Ветки-потомки не разрешены

Ветка поддержки Ветка релиза

36

x.5x.3

ТИПЫ ВЕТОК.ЭКСПЕРИМЕНТАЛЬНЫЕ ВЕТКИ

/trunk

?1x.1

x.0 x.2 x.4

x.7 x.9

x.11

x.6 x.8

x.10Экспериментальная ветка

37

EXPERIMENTAL VS RELEASE BRANCH

Не допускает веток-потомков

Использует строгое именование. Пример: 1.0.x

Использует собственную область значений для нумерации сборок

Рекомендуемый подход к слияниям: после каждой сборки/релиза

Допускает любое число веток-потомков

Правил к именованию не выдвигается. Пример: new_eng_test

Разделяет область значений для нумерации сборок с родственными ветками

Нет рекомендованного подхода к слияниям

Ветка релиза Экспериментальная ветка

38

НАСЛЕДОВАНИЕ БАЗЫИСХОДНОГО КОДА

/trunk

/0.1.x

/1.x.x

/0.2.x

/2.x.x

0.x.x

Последняя разработка

39

НАСЛЕДОВАНИЕ БАЗЫИСХОДНОГО КОДА

Последняя разработка должна содержаться в trunk

40

НАСЛЕДОВАНИЕ БАЗЫИСХОДНОГО КОДА

/trunk

/1.x.x

/3.x.x

/2.x.x

4.x.x3.x.x2.x.x1.x.x

41

ТИПЫ СБОРОК

releases

alpha release

(AR)

beta release

(BR)

release candidate

(RC)stable (ST)

builds

pre-alpha (PA) alpha (A) beta (B)

42

SCM В ДЕЙСТВИИ

/1.x.x

/1.0.x

1.x.x 2.x.x

1.x.0

1.x.1

1.x.2

1.x.3

1.x.4

2.x.0

2.x.1

1.x.5 2.x.2

/trunk

PA

A

Bbuilds

AR

BR

RC

ST

releases

1.0.0

1.0.1

1.0.2 1.0.3

1.0.4

44

SCRUM И SCM

1.x.0 1.x.1 1.x.2

/trunk

1.x.3 1.0.0 1.0.1

sprint backlog

user stories

/1.0.x

demoPA/A AR/BR

45

ИЕРАРХИЯ ДИРЕКТОРИЙ РЕПОЗИТОРИЯ

46

ИЕРАРХИЯ ДИРЕКТОРИЙПРОЕКТ

47

ИЕРАРХИЯ ДИРЕКТОРИЙТЕГИ

48

ИЕРАРХИЯ ДИРЕКТОРИЙВЕТКИ ПОДДЕРЖКИ

trunkPA

A

B

/tags/builds

AR

BR

RC

ST

/tags/releases

1.x.0

1.x.1

1.x.2

1.x.3

2.x.1

1.x.5

1.x.4

2.x.2

2.x.0

/branches/maintenance/versions/1.x.x

/branches/releases/1.0.x

1.0.1

1.0.2 1.0.3

1.0.0

1.0.4

1 12 39 52 73 79 93 112 126 139 155 170 193 201 215 230140

1.x.x 2.x.x

Номера ревизий

49

Заключительное слово

51

Спасибо за внимание!