Как организовать модель ветвления GIT и отливку на стейжинг?

Question

[Username]

Всем привет, прочитал статью: Удачная модель ветвления для Git / Хабр
Модель понравилось, но осталось много вопросов, на которые хочу получить ответы.

Вопросы:

Вводная: Представим что у нас есть 2 ветки: master - куда отливаются релизные версии и develop - куда отливаются тестовые сборки на тестирование QA перед попаданием в мастер. С девелопа запускается автодеплой после чего изменения попадают на стейжинг.

1. Представим что после отливки фичи№1 в девелоп, она прошла QA и мы выпустили новый релиз в мастер. Чтобы не терять времени команда приступила к реализации следующей фичи№2, и уже начала делать коммиты в девелоп и сейчас девелоп находится в нестабильном состоянии, поскольку, то что там есть релизить нельзя. Вдруг в релизной версии №1 обнаруживается баг, для его устранения команда заводит ветку hotfix и сливает исправления в мастер и девелоп. Мне такой подход не нравится, мне хочется, чтобы после исправления бага, новый коммит проходил проверку QA, но как организовать стейжинг пространство в этом случае? Слить код в нестабильный девелоп и выкатиться на стейжинг мы не можем, поскольку изменения девелопа могут нестабильно сказаться на релизе№1. Как быть?
   
   
2. Любой код должен проходить проверку код-ревьювера при отливке в девелоп. Представим что разработчик закончил выполнять фичу№1, отправил её на МР и хочет приступить к фиче №2, но для реализации фичи№2 ему нужен код фичи№1, которая ещё не проверялась код-ревьювером и QA специалистом, откуда разраб должен отпачковываться в данном случае, от девелопа или от ветки с фичой №1?
   
   
3. Представим что в проекте есть 2 фичи, у первой приоритет наивысший у второй чуть ниже, естественно что команда, работающая над фичой№1 делает коммиты и отправляет свой код на слияние в девелоп. Согласно agile вторая команда, работающая над фичой№2 не может отправлять свой код в девелоп, иначе это замедлит поставку нового релиза из фичи№1. Как организовать работу второй команды с точки зрения гит и стейжинг окружения для проверки QA? Создать ветку тест, куда будет отливаться менее приоритетный код? А если таких фичей и команд 5, то нужно будет создавать 5 тестовых веток и стейжингов? Как быть?
   

Заранее спасибо за ответы!

Answer 1

[Vitsliputsli]

1)

мне хочется, чтобы после исправления бага, новый коммит проходил проверку QA, но как организовать стейжинг пространство в этом случае? Слить код в нестабильный девелоп и выкатиться на стейжинг мы не можем, поскольку изменения девелопа могут нестабильно сказаться на релизе№1. Как быть?

А в чем проблема? Отдайте hotfix в QA пусть проверяют. Как в случае feature QA тестирует ветку release-..., так и в случае hotfix, QA тестирует ветку hotfix/... .

2)

откуда разраб должен отпачковываться в данном случае, от девелопа или от ветки с фичой №1?

Если фича №1 зависит от фичи №2, а в dev фича №1 отсутствует, то очевидно, что от ветки фича №1, других вариантов я не вижу.

3)

Согласно agile вторая команда, работающая над фичой№2 не может отправлять свой код в девелоп, иначе это замедлит поставку нового релиза

Наверное agile здесь не при чем. Если работаете по scrum, то каждый спринт это подготовка нового релиза и вы не можете работать над фичей не из этого релиза. git-flow ориентирован именно на такую работу.
Если релизы плавающие, я так понял у вас так, значит не сливайте фичи не из текущего релиза в ветку из которой готовите релиз. Если не выходить за рамки git-flow, то не сливайте в dev ветки не из текущего релиза, QA пусть тестирует либо feature, либо по тегам, если работаете с pull-request, то апрувьте их, но не делайте merge.

Из всего выше описанного, мне кажется у вас 1 единственная сложность, это вопрос как должны работать QA.

Comments

[Username]

Вопрос не про QA, а про организацию под них стейжинг окружений, хочется избежать на проекте 100500 стейжингов, хочется чтобы их количество было статичным.

[Vitsliputsli]

Кол-во стейджингов не связано с кол-вом задач и гитом. Если у вас 1 тестировщик, он может использовать 1 стейджинг, последовательно переходя от одной задачи к другой, собирая для каждой нужный код. И не важно сколько задач ожидают тестирования. Не вижу проблемы.
Если речь про CI и регрессионное автоматизированное тестирование, то их можно прогонять ночью из dev на том же 1 стейдже.
Проблема может быть только в том случае, если тестировщик не управляет процессом сборки.

[Username]

Vitsliputsli,

Проблема может быть только в том случае, если тестировщик не управляет процессом сборки.

Проблема в этом, пока такой процесс не запущен, но в целом QA может через интерфейс менять ветку деплоя, в два клика, в целом мне нравится ваш подход