В современном мире все меняется очень быстро. Слишком быстро. И требования заказчика в том числе. Гибкие методологии разработки позволяют адаптироваться к быстро меняющимся требованиям. Но как сохранить стабильность приложения в данных условиях, как оставить заказчика удовлетворенным и при этом сберечь психическое здоровье разработчиков? Этот доклад о том, как быстро двигаться вперед без опаски оступиться. Презентация подготовлена по материалам выступления Евгения Гавриленко на витебской конференции “Developer's Software Conference” (12.11.2016).

1. Выбираем стратегию
ветвления
ЕВГЕНИЙ ГАВРИЛЕНКО
Ноябрь 12, 2016

2. НОЯБРЬ 12, 2016
В современном мире все меняется очень быстро. Слишком быстро.
И требования заказчика в том числе. Гибкие методологии разработки
позволяют адаптироваться к быстро меняющимся требованиям. Но как
сохранить стабильность приложения в данных условиях, как оставить
заказчика удовлетворенным и при этом сберечь психическое здоровье
разработчиков? Этот доклад о том, как быстро двигаться вперед без
опаски оступиться.

3. 3
• Реализовать новый функционал, не мешая остальным.
• Отвлечься от реализации функционала и починить баг в другом
месте.
• Вовсе отложить начатый функционал до лучших времен.
• Поэкспериментировать с кодом без страха сломать билд.
Зачем нужны бранчи

4. 4
• Реализовать новый функционал, не мешая остальным.
• Отвлечься от реализации функционала и починить баг в другом
месте.
• Вовсе отложить начатый функционал до лучших времен.
• Поэкспериментировать с кодом без страха сломать билд.
Зачем нужны бранчи

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

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

7. 7
• Организовать процесс поэтапного выпуска программы (разработка
- тестирование - релиз), не блокируя разработку следующей
версии.
Зачем нужны бранчи

8. 8
• Организовать процесс поэтапного выпуска программы (разработка
- тестирование - релиз), не блокируя разработку следующей
версии.
Зачем нужны бранчи

9. 9
• Проводить модерацию (кодревью) нового кода перед
непосредственным добавлением в кодовую базу.
• Организовать работу с open source сообществом или
подрядчиком.
Зачем нужны бранчи

10. 10
• Проводить модерацию (кодревью) нового кода перед
непосредственным добавлением в кодовую базу.
• Организовать работу с open source сообществом или
подрядчиком.
Зачем нужны бранчи

11. 11
1. Без ветвлений
2. Ответвление для релиза
3. Ответвления для поддержки
4. Ответвления для задач
Наиболее распространенные сценарии

12. 12
Без ветвлений
master
Tag1.5 Tag2.0

13. 13
Без ветвлений
master
Tag1.5 Tag2.0
Плюсы:
+ Простота
Минусы:
- Нестабильный код в master
- Непредсказуемые даты новых релизов
- Сложности поддержки
- И т.д.

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

15. 15
release
Ответвление для релиза
master

16. 16
release
Ответвление для релиза
master

17. 17
Ответвления для поддержки
release1
master

18. 18
Ответвления для поддержки
release1
master

19. 19
Ответвления для поддержки
release1
master
release2

20. 20
Ответвления для поддержки
release1
master
release2
hotfix

21. 21
Sample

22. 22
Ответвления для задач
master
feature1

23. 23
Ответвления для задач
master
feature1
feature2

24. 24
Ответвления для задач
master
feature1
feature2

25. 25
Ответвления для задач
master
feature1
feature2

26. 26
Стратегия ветвления
Это процесс
Хранить в вики
Утверждаю

27. 27
1. Наличие релизов
2. Необходимость поддержки старых релизов
3. Используемая система контроля версий
4. Продолжительность спринтов
5. И т.д.
От чего оттолкнуться

28. 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
FREEZE
CRITICAL BUG FIXING
GROOMING DEMO PLANNING
Стадии спринта

29. 29
“Git Flow”
master
develop

30. 30
“Git Flow”
master
develop
feature1
feature2

31. 31
“Git Flow”
master
develop
feature1
feature2

32. 32
“Git Flow”
master
develop
feature1
feature2
hotfix

33. 33
“Git Flow”
master
develop
feature1
feature2
hotfix
release

34. 34
“Git Flow”
master
develop
feature1
feature2
hotfix
release

35. 35
“Git Flow”
master
develop
feature1
feature2
hotfix
release

36. 36
“Git Flow”
master
develop
feature1
feature2
hotfix
release

37. 37
“Git Flow”
master
develop
feature1
feature2
hotfix
release

38. 38
“GitHub Flow”
master
feature1
feature2

39. 39
А у нас так
develop
feature1
feature2

40. 40
А у нас так
develop
feature1
feature2
release1

41. 41
А у нас так
develop
feature1
feature2
release1

42. 42
А у нас так
develop
feature1
feature2
release1

43. 43
А у нас так
develop
feature1
feature2
release1

44. 44
А у нас так
develop
feature1
feature2
release1
release2

45. 45
Сохраняйте историю:
git merge <feature> --no-ff.
Пишите комментарии к коммитам и, если система контроля версий позволяет,
добавляйте тэги.
Используйте «хорошие» названия для ветвей.
Полезные советы

46. 46
Вопросы

47. 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