Боль №1: Git Workflow

Терминология• T - время жизни релиза

• t - время работы над задачей

• FEATURE - новый функционал (t ~ T)

• TASK - небольшие улучшения или изменения текущего функционала (t < T)

• BUG - устранение выявленных ошибок в релизе (t << T)

• HOTFIX - устранение выявленных ошибок после релиза limKPI = 0

t→T

Как реализовано сейчас** как должно работать согласно регламенту

Выглядит красиво, но есть нюанс…

1. feature делается не только от master, но и от релизной ветки

2. task и bug делаются от релизной ветки

3. релизов больше, чем зафиксировано в регламенте разработки

4. code review не быстрый (у тимлидов тоже есть задачи)

Реалии эксплуатации

• 2 и 4 -> на релизной ветке копятся pull request, в то время как в master уже ждет feature

• -> +1 -> много релизов в рамках одной ветки: t64.24

• тимлиды разруливают конфликты при слиянии всего этого добра

Следствие

• на релизной ветке копятся pull request, в то время как в master уже ждет feature

• нужно быстрее принимать pull request

• не принимать pull request можно по разным причинам (часто объективным)

• не принятый pull request не должен блокировать релиз - это тупо

• переносить pull request на другую релизную ветку

• git checkout <ticket> && git fetch upstream && git rebase upstream/<new release> [&& resolve conflicts && git rebase --continue] && git push -f origin <ticket>, create pull request - это боль, особенно, когда их было много

• принять pull request в старую ветку, но уже после выкладки нового релиза

• XX -> master [-> resolve conflicts] -> XY [-> resolve conflicts] -> tXY.z -

• много релизов в рамках одной ветки

• по регламенту там вообще должны быть только bugfix и hotfix! - будем следовать регламенту

• тимлиды разруливают конфликты при слиянии всего этого добра

• разработчик лучше знает контекст своей задачи - логично перекинуть это на него

Это еще не всё - проблемы централизации

1. главный репозиторий напоминает помойку

2. когда у всех есть доступ на запись

Как насчет преимуществ DVCS?!

Решаемые задачи

Основная:уменьшить время между принятием pull request и релизом (мечты о Continuos Delivery)

Дополнительные:уменьшить головную боль, связанную с переброской pull request уменьшить риски ошибок при разруливании конфликтов при подготовке релизов

Приступим

Уже все давно придумано** спасибо Vincent Driessen!

Gitflow Workflow

Детали

Feature Branches

Release Branches

Maintenance Branches

Учтем опыт эксплуатации• команда не такая большая, code reviewer’ов всего 1-2 человека на проект, а релизные ветки - это еще один слой, на который тратится время

• вместо релизных веток - 2 часа «тишины» (при этому делать pull request никто не запрещает, но и на dev они не попадут до релиза)

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

• переходим на форки с read-only доступом к главному репозиторию (upstream)

• https://www.atlassian.com/git/tutorials/comparing-workflows

• https://github.com/nvie/gitflow

• http://professionalservices.matrixresources.com/blog/why-distributed-version-control-systems

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

используй Gitflow

Спасибо за внимание!

Есть вопросы?

Камиль Самигуллин какой-то разработчик

kamil@samigullin.info @ikamilsk github.com/kamilsk