«GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков
1 like1,431 views
Особенности модели Github-flow и нюансы её внедрения в основную ветку разработки.
More Related Content
What's hot (16)
Viewers also liked (20)
Similar to «GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков (20)
«GitHub Flow — немного сложнее, чем на бумаге», Александр Бирюков
- 1. Github Flow. Немного сложнее, чем на бумаге Александр Бирюков, Руководитель группы разработки ПО, 2GIS
- 2. Александр Бирюков Руководитель группы разработки ПО Куратор секции FrontEnd Люблю JavaScript 2
- 7. GitHub Flow
- 8. 6 принципов GitHub Flow 1. master всегда в рабочем состоянии и готов к деплою 2. Каждая новая ветвь создаётся от master и имеет понятное название 3. Постоянно актуализируйте удалённую ветвь и локальную 4. В любой момент времени создавайте Pull Request 5. Вливайте ветвь только после того как кто-то просмотрел изменения 6. Как только изменения попали в master их следует задеплоить 8
- 9. 6 принципов GitHub Flow 1. master всегда в рабочем состоянии и готов к деплою 2. Каждая новая ветвь создаётся от master и имеет понятное название 3. Постоянно актуализируйте удалённую ветвь и локальную 4. В любой момент времени создавайте Pull Request 5. Вливайте ветвь только после того как кто-то просмотрел изменения 6. Как только изменения попали в master их следует задеплоить 9
- 10. #4 и #5 — Pull Request merge master • Большая команда — генерирует много PR • Подвисший PR быстро устаревает (1,5 мес) • Две системы трекинга — Github и ваша внутренняя • Достаточно ли ревью чтобы слить задачу в master? 10
- 11. #4 и #5 — Что пришлось сделать • Оповещаем о самых срочных PR • Утром и после обеда каждый выделяет время на ревью • Ревью минимум от 2-х членов команды • Подружили JIRA и Github • В JIRA держим задачи и ориентируемся на все статусы • В Github ведём только CodeReview • Написали расширение к Chrome для отображения статуса PR 11
- 13. 6 принципов GitHub Flow 13 1. master всегда в рабочем состоянии и готов к деплою 2. Каждая новая ветвь создаётся от master и имеет понятное название 3. Постоянно актуализируйте удалённую ветвь и локальную 4. В любой момент времени создавайте Pull Request 5. Вливайте ветвь только после того как кто-то просмотрел изменения 6. Как только изменения попали в master их следует задеплоить
- 14. #2 и #3 — Разработка в ветках • Актуализируем локальную ветку — merge vs. rebase • Актуализируем удалённу ветку — force push после rebase Нужно хорошо знать и уметь пользоваться git 14
- 15. #2 и #3 — Что пришлось сделать 1. Принять ряд соглашений по работе с ветками • Именование веток • Описать жизненный цикл • Нет множественному ветвлению 2. Провести 2 внутренних семинара по использованию git 15
- 16. 6 принципов GitHub Flow 16 1. master всегда в рабочем состоянии и готов к деплою 2. Каждая новая ветвь создаётся от master и имеет понятное название 3. Постоянно актуализируйте удалённую ветвь и локальную 4. В любой момент времени создавайте Pull Request 5. Вливайте ветвь только после того как кто-то просмотрел изменения 6. Как только изменения попали в master их следует задеплоить
- 17. #1 и #6 — Деплоить!!1 • Готов к деплою — протестирован • В порядке поступления — быстро 17
- 18. #1 и #6 — Деплоить!!1 Тестируется быстро • Есть богатый набор тестов всех уровней • Jenkins или любая другая система Выкатывается быстро • Есть система автоматической сборки проекта • Ansible, Chef или любая другая система 18
- 19. #1 и #6 — Что пришлось сделать 19 • Дополнить базу тестов почти на 50% — ~3 недели работы • Группы тестов для каждого этапа • Настроить Jenkins на организацию автоматических сборок и прогона финального набора тестов • Процесс и инфраструктура для выкладки проекта
- 20. Итого, нам пришлось сделать 20 • В срочном порядке дописывать недостающие автотесты • Полностью перенастроить систему автоматизированного тестирования (CI) • По максимуму автоматизировать и отладить процесс доставки кода на бой (CD) • Принять несколько дополнительных командных соглашений • Написать расширение для браузера для синхронизации Jira+Gihub • Провести несколько тренингов/презентаций по Git
- 21. Каких результатов достигли • На проекте есть честный CodeReview • Более 1000 F-тестов которые реально помогают • Пул из ~10-15 PR • 5-7 на ревью • 5-7 готовы к тестированию • Самый старый PR - 8-12 дней • 1 QA в день интегрирует 2-4 PR. Т.е 4-12 PR/день • Последняя ретроспектива - GithubFlow круто! 21
- 22. GitHub Flow — это действительно круто!
- 23. Спасибо! Вопросы? Александр Бирюков a.biryukov@2gis.ru @illbullet http://2gis.ru, http://beta.2gis.ru
- 24. Git Flow The 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
- 25. Команда профессионалов • 1 Project Manager • 1 Team Lead • 9 JS Developers • 4 FE Developers • 3 QA 25