Git flow с тестированием?

Question

[Дмитрий Гавриленко]

Добрый день.
Хочу в компании продвинуть гит как основную систему контроля версий. Сейчас используется TFS. Раньше работал с gitflow, но пока не могу себе отдавать ответ о том, что гит потянет текущий процесс внедрения.

И так. Сейчас есть 3 стадии разработки продукта.
Релизы постоянные.
Первая стадия дев. Разработка работает.
Вторая стадия тестирование. Работают тестировщики и аналитики.
Третья стадия прод. Релиз.

Процесс такой. Из дева доработка попадает на тестирование. Если тестирование проходит, то из дева доработка попадает на прод.

Ок. Мои предположения как это можно сделать в рамках gitflow.

Все создаваемые feature пушатся не в dev на удаленном репозитории, а в какой нибудь test. И если в test моя доработка проходит тестирование, тогда уже я пушу в dev, там допустим на каком нибудь Gitlab проводят ревью и мержут в master который является prod веткой.
Далее release ветки и все.

В принципе не плохо, но закрытия фьючи не будет происходить, потому что есть gitlab который пушит в мастер. Это мелочи. Если есть предложения по улучшению схемы, напиши пожалуйста.

И ещё вопрос. Я не ниндзя в Гите. Вот допустим, случилось так, что я пушнул на test доработки и что-то критическое нагнулось. После меня пушнуло ещё 6 человек. В Гите можно как-то вырезать мой коммит или хотя бы откатить всю ветку до нужно состояния?

Comments

[rustler2000]

0. Не понятно процесс - девы в feature->мерж в test->тестеры репортят кудато?->девы(другие?) делают ревью и мерж в master->опять тестеры->release в prod ?
1. На gitflow это мало похоже, но скорее похоже на gerrit

[Влад Григорьев]

Я работал по двум нормальным схемам:
1. все изменения идут через пул реквест, и собирается релиз, он теститься, чиниться, потом едет в прод, потом следующий релиз
2. Релиз собирается по тегу в гите, все изменения которые ниже него попали в релиз, все что выше нет, все правки идут через теги, например версия 1.1, потом 1.1

В первом случае контроль за текущей версией, больше, так как в релиз не чего лишнего не попадает, можно еще каждый пул реквест тестить отдельно, но это врядли про ваш случай

Answer 1

[rustler2000]

То что вы называете "тестированием" есть "приемка".
Тестировать надо в своих ветках и в develop. CI в помощь.
Ревью делать при мержах в develop а не после приемки.
С ревью git flow фигово живет. Но никто не мешеает работать с брэнчами "как в git flow".

Develop надо будет тагать с суфиксами, чтобы потом релиз начинать с тага. Тут почти как в "git flow". И потом пусть приемка играется в своем брэнче. Собственно по git flow они и будут в release брэнче работать.

И это если все с монорепо.

Откатывать develop не есть хорошо, потому если что сломали - ну и фиг с ним - develop не гарантирует работоспособности - починили отдельным мержем.

UPD: хехе память не подвела - https://habrahabr.ru/company/infopulse/blog/345826/

Answer 2

[GTRxShock]

думаю, идея gitflow не совсем усвоилась https://habrahabr.ru/post/106912/
фичи делаются в отдельных ветках, по готовности собираются в релиз (через PR), он отправляется на тест, долетают багфиксы, в итоге все катится на бой и так в цикле. Устаканившийся релиз вливается в мастер. Плюс возможны небольшие отступления из-за специфики процессов разработки в кампании, но вектор в большинстве случаев один и тот же

Comments

[rustler2000]

Вообщето это же и есть статья по git flow.
У топик стартера же какаято гидра типа multistage git flow

[GTRxShock]

вот я и надеялся, что после очередного прочтения требования станут более консервативными и большинство вопросов отпадет)