Post on 27-Jul-2015
Терминология• 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! - будем следовать регламенту
• тимлиды разруливают конфликты при слиянии всего этого добра
• разработчик лучше знает контекст своей задачи - логично перекинуть это на него
Решаемые задачи
Основная:уменьшить время между принятием pull request и релизом (мечты о Continuos Delivery)
Дополнительные:уменьшить головную боль, связанную с переброской pull request уменьшить риски ошибок при разруливании конфликтов при подготовке релизов
Учтем опыт эксплуатации• команда не такая большая, 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
Полезные ссылки
Спасибо за внимание!
Есть вопросы?
Камиль Самигуллин какой-то разработчик
kamil@samigullin.info @ikamilsk github.com/kamilsk