Что такое next release?
Начал использовать git-flow. Мне предлагается выбрать ветку для production release:
Which branch should be used for bringing forth production releases?
- DVR-1570
- DVR-1573
- develop
- master
Branch name for production releases: [master]
Здесь всё понятно. Не ясен следующий тезис:
Which branch should be used for integration of the "next release"?
- DVR-1570
- DVR-1573
- develop
Branch name for "next release" development: [develop]
Что такое next release? У нас некст релиз всегда была фича-бранч. В них всё тестировалось и уезжало в мастер сразу и деплоился контейнер.
Поясните, что такое next release?
Ответы (1 шт):
next release ветка нужна в большой команде для распараллеливания разработки и тестирования.
Вот представьте, у вас команда из 10 разработчиков. Каждый из них начинает работу над фичей F1, F2, ... F10. Каждая из них порождена от некоторого комита R1.
Допустим, используется простой процесс, когда ветку с фичей сразу сливаем в master и разворачиваем на проде.
Когда готова F1 - все в порядке, слили и все нормально. Но дальше возникают проблемы. В F2 у нас нет изменений из F1 (ведь эта ветка порождена от R1). Тут возникает дилемма: надеяться что изменения в F1 и F2 никак друг на друга не влияют (тогда можно F2 тестировать в ветке и сливать в develop) или сливать master в F2 и тестировать что и F1 и F2 работают как нужно.
Так как работа ведется параллельно, и веток типа F2 у нас много, то возникают проблемы с тем, что один и тот же функционал (в данном случае F1) потенциально нужно тестировать в F2-F10 несколько раз. А еще если учесть что после слияния, скажем, F2 в master нужно будет делать то же и для F2, то количество таких проблем возрастает.
Есть несколько способов как решить (или смягчить) проблему и схема с next release это один из них. В этом подходе каждая фича тестируется отдельно в ветке с фичей, потом сливается в next release ветку, и когда все F1-F10 слиты, делается один раунд тестирования (в этом месте его можно распараллелить). Если все нормально, то делается релиз.
Альтернативные способы решить эту проблему (и сливать ветки с фичами в develop напрямую):
- делать так, чтоб изменения в F1 - F10 не могли друг на друга влиять
- хорошее покрытие автоматическими тестами (по сути необходимость повторного многократного тестирования фич тут не проблема, так как все автоматизировано и мы можем это себе позволить).
- держать маленькие команды. Тогда накладные расходы на перекрестное тестирование не такие большие (особенно если еще и пункты 1-2 на каком-то уровне), как расходы на поддержание более сложного и медленного процесса.