Comments 8
Хорошее, доступное объяснение GitFlow. Спасибо.
Однако ситуация "bug на prod" который требует немедленной реакции не раскрыта совсем.
Ок. ответвились от master, но вливаться из bug в master ? совсем без тестирования? не выглядит безопасным. А поскольку про тесты на feature|bug ветках вы не рассказывали, то я бы рекомендовал все таки путь "master->bug->test->master" чтобы путь релиза "test-master" не нарушался.
И интересны ситуации
"спринт В уже хочет на test, но там еще результаты спринта Б, который проверен на 80% и ожидается, что установка на prod через N дней допустим". Что делаете?
или еще интереснее и по мне так вероятнее
"спринт Б установлен на test, и в тот же день приходит critical-bug с prod от спринта А"
Ок. ответвились от master, но вливаться из bug в master ? совсем без тестирования? не выглядит безопасным. А поскольку про тесты на feature|bug ветках вы не рассказывали, то я бы рекомендовал все таки путь "master->bug->test->master" чтобы путь релиза "test-master" не нарушался.
Да, согласен, но есть момент. Тестировать что-то на IFT в таком случае имеет смысл, если баг воспроизвёлся на IFT. Если баг на IFT не воспроизводится, тогда мы в любом случае не сможем протестировать его исправление, и максимум, что мы сможем сделать - это регресс на IFT после исправления. Тогда подойдёт путь master -> bug -> master -> test -> регресс на тесте -> релиз в мастере. На целостность кода это, по сравнению с Вашим способом, не повлияет, но путаницы будет немного меньше, чем возврат ветки bug к родителю через другую ветку.
"спринт В уже хочет на test, но там еще результаты спринта Б, который проверен на 80% и ожидается, что установка на prod через N дней допустим". Что делаете?
Ситуация знакомая :) Но тут всё просто. Спринт В может захотеть на тест только после а) выполнения всех задач спринта б) успешного тестирования на деве в) code freeze. Если команда находится на этапе отладки предыдущего спринта, а Вы уже сделали все задачи следующего, значит, Вы недооценили свои силы на спринт :) Что ж, попросите добавить в свой скоуп на спринт ещё задач :)
"спринт Б установлен на test, и в тот же день приходит critical-bug с prod от спринта А"
Хорошо, если можно вернуть стенд в состояние спринта А и воспроизвести баг на IFT, но, к сожалению, не каждый в каждом случае спринт можно откатить до состояния предыдущего релиза, да и стоимость такого отката может превышать профит от починки такого бага. git flow в любом случае будет master -> bug -> master; далее, в зависимости от состояния IFT, или регресс на IFT, или скользкая дорожка внепланового релиза на прод без регресса (тестируем на проде), после успешного исправления бага master -> test -> develop. К сожалению, такое тоже бывает.
Ох тяжело вам будет с таким подходом в контейнеры деплоиться. В манифесте 12factor app первым же пунктом - обеспечьте деплой любой ветки на любое окружение.
Да и стендов маловато. Весь флоу превратится в хаос, когда из будет хотя бы штук 5.
А можете песотовать что-то на тему "как подружить гит с микросервисами"? Вроде подавляющее количество статей про гитфлоу описывают плюс-минус то же самое, что и в текущем топике
Мне кажется, это ортогональные вещи. В микросервисной архитектуре можно работать по любому флоу. Именно у нас используется GitHub flow с одним master и линейной историей; если бы делали коробочное решение (или надо было поддерживать несколько версий), то логично было бы использовать GitLab flow.
Основная странность GitFlow в подобных схемах - это непонятно, для чего ветка master существует.
Вот, скажем, собрали мы для тестовой стреды в ветке test из коммита X некий артефакт.
Протестировали, он оказался годным. Теперь этот же самый артефакт без всякой пересборки можно в эксплуатацию ставить. Или на какой-нибудь другой стенд, для другого тестирования. Но мы зачем-то мержим коммит X в ветку master. И потом из получившегося коммита Y либо заново собираем (но тогда получается новый артефакт из другого коммита, который надо бы заново тестировать), либо просто игнорируем и оставляем в качестве признака "мы признали эту сборку стабильной".
И смысл тогда эту ветку держать? Ведь для фиксации состояния на конкретный момент времени у Git есть механизм тегов. Им и надо пользоваться. Просто ставим тег с версией вида "release/a.b.c" и от наличиях всех этих тегов всю оставшуюся автоматику строим.
Спасибо за статью! Было интересно почитать.
Когда работал руководителем разработки в "соседнем" банке, я внедрял похожую схему на основе git-flow. У нас было побольше контуров, ИФТ было два и по пути на прод код успевал побывать ещё на ПСИ(приемо-сдаточные испытания). Держать такое количество веток было бы тяжело и привело бы к множеству ошибок, поэтому у нас было 3 ветки: develop, release, master. В начале спринта мы отводили релизную ветку от дева. Чаще всего с головы ветки. Очень-очень редко приходилось брать с предидущих коммитов. От релизной ветки отводили фичи и делали merge назад. Если требовалось тестирование на develop, то мержили release в dev. По окончанию работ проставляли теги RC(release candidate) на release ветке и выкатывали на ифт. Когда тетстирование давало добро, то RC отправлялся на ПСИ. После прохождения AppSec и прочих радостей мержили в мастер и ставили релизный тег. Ветка релиз мержилась как в master так и в develop. При обнаружении бага на проде от мастера отводили bugfix, далее он проходил ИФТ->ПСИ->AppSec и мержился в мастер и проставляли тэг с инкрементом патча(по SemVer). В develop ветке вели разработку на следующий спринт либо очень долгих фичей.
P.S. У вас знакомый ник, мне кажется мы с вами году в 2016 вместе проходили курс Кислина. Или я ошибаюсь?
GitFlow в его простоте от dev до prod