Вячеслав Бирюков - Linux инструменты системного администратора
«GitHub Flow — немного сложнее, чем на бумаге», Александр...
description
Transcript of «GitHub Flow — немного сложнее, чем на бумаге», Александр...
Github Flow. Немногосложнее, чем на бумаге
Александр Бирюков, Руководитель группы разработки ПО, 2GIS
Александр БирюковРуководитель группы разработки ПО
Куратор секции FrontEnd
Люблю JavaScript
2
GitHub Flow
6 принципов GitHub Flow1. master всегда в рабочем состоянии и готов к деплою
2. Каждая новая ветвь создаётся от master и имеет понятное название
3. Постоянно актуализируйте удалённую ветвь и локальную
4. В любой момент времени создавайте Pull Request
5. Вливайте ветвь только после того как кто-то просмотрел изменения
6. Как только изменения попали в master их следует задеплоить
8
6 принципов GitHub Flow1. master всегда в рабочем состоянии и готов к деплою
2. Каждая новая ветвь создаётся от master и имеет понятное название
3. Постоянно актуализируйте удалённую ветвь и локальную
4. В любой момент времени создавайте Pull Request
5. Вливайте ветвь только после того как кто-то просмотрел изменения
6. Как только изменения попали в master их следует задеплоить
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
6 принципов GitHub Flow1. master всегда в рабочем состоянии и готов к деплою
2. Каждая новая ветвь создаётся от master и имеет понятное название
3. Постоянно актуализируйте удалённую ветвь и локальную
4. В любой момент времени создавайте Pull Request
5. Вливайте ветвь только после того как кто-то просмотрел изменения
6. Как только изменения попали в master их следует задеплоить
13
#2 и #3 — Разработка в ветках• Актуализируем локальную ветку — merge vs. rebase
• Актуализируем удалённу ветку — force push после rebase
Нужно хорошо знать и уметь пользоваться git
14
#2 и #3 — Что пришлось сделать1. Принять ряд соглашений по работе с ветками
• Именование веток
• Описать жизненный цикл
• Нет множественному ветвлению
2. Провести 2 внутренних семинара по использованию git
15
6 принципов GitHub Flow1. master всегда в рабочем состоянии и готов к деплою
2. Каждая новая ветвь создаётся от master и имеет понятное название
3. Постоянно актуализируйте удалённую ветвь и локальную
4. В любой момент времени создавайте Pull Request
5. Вливайте ветвь только после того как кто-то просмотрел изменения
6. Как только изменения попали в master их следует задеплоить
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 — это
действительнокруто!
@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