Поддерживаем разработку нескольких версий продукта в GitУправление командой разработки (тимлиды)
Больше трёх лет развивает Apache Ignite в GridGain, отвечает за поддержку клиентов и пилотные проекты в роли Head of Customer Solutions. В прошлом - разработчик Java Platform Group в Oracle.
Давайте признаем: все ненавидят обновлять свой production. И если ваши пользователи — крупные корпорации, банки и финтех, это приносит не только деньги, но и требования поддерживать старые версии и их стабильность.
Поддержка нескольких версий продукта — это сложно. Если пустить всё на самотёк, то рано или поздно случится коллапс: будут появляться регрессии (фикс попадёт в 1.1, но потеряется в 1.2), выпуск версий будет замедляться из-за хаоса в release scope.
Мы изучали и пробовали разные подходы, поняли, что для нас работает, а что — нет. В результате мы сформировали собственный процесс работы с Git, который позволяет нам поддерживать десятки предыдущих версий, избегать регрессий и проблем с совместимостью и оставаться гибкими в выпуске maintenance- и hot fix-релизов.
Расскажу:
— как мы поняли, что нам нужен формализованный процесс по работе с версиями;
— почему git-flow — не панацея;
— почему мы запрещаем merge, не ставим tags и не делаем forward ports;
— как выглядит наш workflow сегодня и как построить такой же у себя;
— почему наш workflow — тоже не панацея.
