Выбираем стратегию

ветвления

ЕВГЕНИЙ ГАВРИЛЕНКО

Ноябрь 12, 2016

НОЯБРЬ 12, 2016

В современном мире все меняется очень быстро. Слишком быстро.

И требования заказчика в том числе. Гибкие методологии разработки

позволяют адаптироваться к быстро меняющимся требованиям. Но как

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

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

разработчиков? Этот доклад о том, как быстро двигаться вперед без

опаски оступиться.

3

• Реализовать новый функционал, не мешая остальным.

• Отвлечься от реализации функционала и починить баг в другом

месте.

• Вовсе отложить начатый функционал до лучших времен.

• Поэкспериментировать с кодом без страха сломать билд.

Зачем нужны бранчи

4

• Реализовать новый функционал, не мешая остальным.

• Отвлечься от реализации функционала и починить баг в другом

месте.

• Вовсе отложить начатый функционал до лучших времен.

• Поэкспериментировать с кодом без страха сломать билд.

Зачем нужны бранчи

5

• Получить запрос на доработку старой версии программы от

заказчика и поддерживать далее несколько версий ПО.

Зачем нужны бранчи

6

• Получить запрос на доработку старой версии программы от

заказчика и поддерживать далее несколько версий ПО.

Зачем нужны бранчи

7

• Организовать процесс поэтапного выпуска программы (разработка

- тестирование - релиз), не блокируя разработку следующей

версии.

Зачем нужны бранчи

8

• Организовать процесс поэтапного выпуска программы (разработка

- тестирование - релиз), не блокируя разработку следующей

версии.

Зачем нужны бранчи

9

• Проводить модерацию (кодревью) нового кода перед

непосредственным добавлением в кодовую базу.

• Организовать работу с open source сообществом или

подрядчиком.

Зачем нужны бранчи

10

• Проводить модерацию (кодревью) нового кода перед

непосредственным добавлением в кодовую базу.

• Организовать работу с open source сообществом или

подрядчиком.

Зачем нужны бранчи

11

1. Без ветвлений

2. Ответвление для релиза

3. Ответвления для поддержки

4. Ответвления для задач

Наиболее распространенные сценарии

12

Без ветвлений

master

Tag1.5 Tag2.0

13

Без ветвлений

master

Tag1.5 Tag2.0

Плюсы:

+ Простота

Минусы:

- Нестабильный код в master

- Непредсказуемые даты новых релизов

- Сложности поддержки

- И т.д.

14

Ответвление для релиза

master

15

release

Ответвление для релиза

master

16

release

Ответвление для релиза

master

17

Ответвления для поддержки

release1

master

18

Ответвления для поддержки

release1

master

19

Ответвления для поддержки

release1

master

release2

20

Ответвления для поддержки

release1

master

release2

hotfix

21

Sample

22

Ответвления для задач

master

feature1

23

Ответвления для задач

master

feature1

feature2

24

Ответвления для задач

master

feature1

feature2

25

Ответвления для задач

master

feature1

feature2

26

Стратегия ветвления

Это процесс

Хранить в вики

Утверждаю

27

1. Наличие релизов

2. Необходимость поддержки старых релизов

3. Используемая система контроля версий

4. Продолжительность спринтов

5. И т.д.

От чего оттолкнуться

28

TUESDAY WEDNESDAY THURSDAY FRIDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY MONDAY

USER

STORIES

BREAKDOWN

TEST CASES COMPOSING

DEVELOPMENT & BUG FIXING

TESTING REGRESSION TESTING

FEATURE

FREEZE

CODE

FREEZECRITICAL BUG FIXING

GROOMING DEMO PLANNING

Стадии спринта

29

“Git Flow”

master

develop

30

“Git Flow”

master

develop

feature1

feature2

31

“Git Flow”

master

develop

feature1

feature2

32

“Git Flow”

master

develop

feature1

feature2

hotfix

33

“Git Flow”

master

develop

feature1

feature2

hotfix

release

34

“Git Flow”

master

develop

feature1

feature2

hotfix

release

35

“Git Flow”

master

develop

feature1

feature2

hotfix

release

36

“Git Flow”

master

develop

feature1

feature2

hotfix

release

37

“Git Flow”

master

develop

feature1

feature2

hotfix

release

38

“GitHub Flow”

master

feature1

feature2

39

А у нас так

develop

feature1

feature2

40

А у нас так

develop

feature1

feature2

release1

41

А у нас так

develop

feature1

feature2

release1

42

А у нас так

develop

feature1

feature2

release1

43

А у нас так

develop

feature1

feature2

release1

44

А у нас так

develop

feature1

feature2

release1

release2

45

Сохраняйте историю:

git merge <feature> --no-ff.

Пишите комментарии к коммитам и, если система контроля версий позволяет,

добавляйте тэги.

Используйте «хорошие» названия для ветвей.

Полезные советы

46

Вопросы

47

Полезные ссылки

• http://nvie.com/posts/a-successful-git-branching-model/

• http://scottchacon.com/2011/08/31/github-flow.html

• https://msdn.microsoft.com/en-us/library/bb668955.aspx

• https://ashamray.wordpress.com/stati_hf/microsoft_vs/visual_studio_tfs_branching_guid

e_2010/tfs_branching_guidance_2010_main/

• https://www.visualstudio.com/en-us/docs/tfvc/branch-strategically