i
Дефолтная ветка - develop, релизная/прод - master, после мержа в develop делать автоматически чери-пик в релизную ветку мастер. Вот такая магия
А если не катите мердж, а ещё 3 раза пытаетесь?
Size: a a a
2020 May 05
C☭
В этом подходе есть и удобства и неудобства, но это не тема для спора
я бы подискутировал на данную тему,,, а то у нас сейчас на этой волне "конфликт интересов" на работе между командами
C☭
Дефолтная ветка - develop, релизная/прод - master, после мержа в develop делать автоматически чери-пик в релизную ветку мастер. Вот такая магия
да это понятно... непонятно почему так надо?
C☭
В вашем варианте например нельзя тестить сразу 3 разных релиза
согласен... в данном случае у нас нет параллельных сборок версии в силу отсутствия как таковых.. релиз делаем раз в квартал и пока достаточно
DK
да это понятно... непонятно почему так надо?
Наверное мы вверх ногами поняли gitflow тогда (?
C☭
Типа этот релиз завтра, этот через 2 дня, этот в понедельник, этот срочно прямо сейчас катим
но этот кейс решается бранчами с тестовым окружением.. и его уже можно мержить в staging...
те иметь предрелизные ветки вида
release/1.2.3
release/1.2.4
release/1.3.0
и их инкрементально пушить в staging по мере необходимости
те иметь предрелизные ветки вида
release/1.2.3
release/1.2.4
release/1.3.0
и их инкрементально пушить в staging по мере необходимости
DK
но этот кейс решается бранчами с тестовым окружением.. и его уже можно мержить в staging...
те иметь предрелизные ветки вида
release/1.2.3
release/1.2.4
release/1.3.0
и их инкрементально пушить в staging по мере необходимости
те иметь предрелизные ветки вида
release/1.2.3
release/1.2.4
release/1.3.0
и их инкрементально пушить в staging по мере необходимости
Этот подход юзаем. Хотим попробовать gitflow...
i
но этот кейс решается бранчами с тестовым окружением.. и его уже можно мержить в staging...
те иметь предрелизные ветки вида
release/1.2.3
release/1.2.4
release/1.3.0
и их инкрементально пушить в staging по мере необходимости
те иметь предрелизные ветки вида
release/1.2.3
release/1.2.4
release/1.3.0
и их инкрементально пушить в staging по мере необходимости
Зачем инкрементально, если тебе на staging одновременно 3 разных ветки надо тестить и это 3 стенда?
C☭
Этот подход юзаем. Хотим попробовать gitflow...
C☭
Зачем инкрементально, если тебе на staging одновременно 3 разных ветки надо тестить и это 3 стенда?
а бэкэнд в данном случае тоже меняетя или один и тот же?