«GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков

Github Flow. Немногосложнее, чем на бумаге

Александр Бирюков, Руководитель группы разработки ПО, 2GIS

http://2gis.ru/

Александр БирюковРуководитель группы разработки ПО

Куратор секции FrontEnd

Люблю JavaScript

2

GitHub Flow

6 принципов GitHub Flow1. master всегда в рабочем состоянии и готов к деплою

2. Каждая новая ветвь создаётся от master и имеет понятное название

3. Постоянно актуализируйте удалённую ветвь и локальную

4. В любой момент времени создавайте Pull Request

5. Вливайте ветвь только после того как кто-то просмотрел изменения

6. Как только изменения попали в master их следует задеплоить

8







9

#4 и #5 — Pull Request merge master• Большая команда — генерирует много PR

• Подвисший PR быстро устаревает (1,5 мес)

• Две системы трекинга — Github и ваша внутренняя

• Достаточно ли ревью чтобы слить задачу в master?

10

#4 и #5 — Что пришлось сделать• Оповещаем о самых срочных PR

• Утром и после обеда каждый выделяет время на ревью

• Ревью минимум от 2-х членов команды

• Подружили JIRA и Github

• В JIRA держим задачи и ориентируемся на все статусы

• В Github ведём только CodeReview

• Написали расширение к Chrome для отображения статуса PR

11







13

#2 и #3 — Разработка в ветках• Актуализируем локальную ветку — merge vs. rebase

• Актуализируем удалённу ветку — force push после rebase

Нужно хорошо знать и уметь пользоваться git

14

#2 и #3 — Что пришлось сделать1. Принять ряд соглашений по работе с ветками

• Именование веток

• Описать жизненный цикл

• Нет множественному ветвлению

2. Провести 2 внутренних семинара по использованию git

15







16

#1 и #6 — Деплоить!!1• Готов к деплою — протестирован

• В порядке поступления — быстро

17

#1 и #6 — Деплоить!!1Тестируется быстро

• Есть богатый набор тестов всех уровней

• Jenkins или любая другая система

Выкатывается быстро

• Есть система автоматической сборки проекта

• Ansible, Chef или любая другая система

18

#1 и #6 — Что пришлось сделать• Дополнить базу тестов почти на 50% — ~3 недели работы

• Группы тестов для каждого этапа

• Настроить Jenkins на организацию автоматических сборок и прогона

финального набора тестов

• Процесс и инфраструктура для выкладки проекта

19

Итого, нам пришлось сделать• В срочном порядке дописывать недостающие автотесты

• Полностью перенастроить систему автоматизированного

тестирования (CI)

• По максимуму автоматизировать и отладить процесс доставки кода на

бой (CD)

• Принять несколько дополнительных командных соглашений

• Написать расширение для браузера для синхронизации Jira+Gihub

• Провести несколько тренингов/презентаций по Git

20

• На проекте есть честный CodeReview

• Более 1000 F-тестов которые реально помогают

• Пул из ~10-15 PR

• 5-7 на ревью

• 5-7 готовы к тестированию

• Самый старый PR - 8-12 дней

• 1 QA в день интегрирует 2-4 PR. Т.е 4-12 PR/день

• Последняя ретроспектива - GithubFlow круто!

Каких результатов достигли

21

GitHub Flow — это

действительнокруто!

[email protected]

@illbullet

http://2gis.ru, http://beta.2gis.ru

Спасибо! Вопросы?Александр Бирюков

mailto:[email protected]

http://twitter.com/illbullet

http://2gis.ru/

http://beta.2gis.ru/

Git FlowThe primary reason for moving away is that the git-flow process is hard to

deal with in a continuous (or near-continuous) deployment model.

Nicholas C. Zakas

The general feeling is that git-flow works well for products in a more

traditional release model, where releases are done once every few weeks....

Nicholas C. Zakas

““

24

• 1 Project Manager

• 1 Team Lead

• 9 JS Developers

• 4 FE Developers

• 3 QA

Команда профессионалов

25

Software

«GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков