Здравствуйте, Ziaw, Вы писали:

Z>·>Вот тут "стартуем ветку от release, вливаем в develop" — прежде чем влить в девелоп, надо с ним замержиться
Z>Не надо так делать. Вливать мастер в релиз у нас нельзя, соответственно и в ветки его никто не вливает. Если делать как ты предлагаешь, весь смысл схемы теряется сразу.
Делаешь ты push из task в develop, а он говорит, что diverged и конфликты. Тебе надо вначале вытянуть из develop в task, разрешить конфликты, потом push. Т.е. в task оказываются рандомные коммиты из develop.

Z>весь смысл схемы теряется сразу.
Было бы что терять.

Z>·>Да, ещё веселуха начинается, когда таск T завершен, залит в девелоп, а QA сейчас заняты и начинают тестировать неделю спустя. Вроде всё ок, аппрув дали — мол, вливайте в релиз, happy days! А чувак который пилил T на больничный ушел и вообще за неделю уже всё забыл после пьянки. При вливании обнаруживаются конфликты и никто толком не знает как их правильно разрешать... В итоге простой случай должен быть самым простым и частым — головная боль.
Z>Что за проект такой, что конфликты вливания дело настолько частое и нетривиальное? В таком проекте я крайне не рекомендую флоу с двойным вливанием.
Тривиально когда ты вливаешь сейчас. А через неделю уже может быть нетривиально.

Z>·>В моей схеме такого просто нет. Все мерж-конфликты разрешаются тут же. Я даже пайплайн настраивал — при сборке хотфикса в релизной ветке — вначале происходит автомерж в девелоп, потом только сборка проекта.
Z>Ну да, в гитфлоу мердж один. Ты как будто только что обнаружил, что в моей схеме два мерджа на одну таску, хотя об этом сразу было сказано.
Я обнаружил, и начал разговор с объяснений, что два мержа — это кака, мучительно, ненадёжно и никаких преимуществ.

Z>·>Почти. Только "потом начинается тестирование всего" — это QA полной интерации всего и вся, а не конкретной таски.
Z>Ты уклоняешься от описания процесса тестирования тасок и заявляешь о том, что это должны делать юниттесты. Описываемая схема именно для тестирования тасок.
Видов тестирования несколько. Поэтому задавай вопрос точнее. Таски QA тестирует в девелоп бранче. И именно от девелоп бранча создаются релизные таги — релизится ровно та же sha1 ревизия, что была протестирована.

Z>·>Это ещё зависит от разных проектов. В одном из проектов QA команда тестирует релиз предыдущего спринта.
Z>·>В другом проекте как таковой команды QA не было. В конце спринта делается таг и деплоится для теста как "релиз-кандидат" в staging. Потом каждый проверяет свои завершенные таски, кликая кнопки в нужном порядке, проверяя логи, что без ошибок, и т.п. — но тут не надо тестировать все возможные сценарии, которые уже покрыты юнит-тестами, а только общую интеграцию.
Z>·>В ещё другом проекте на теге гонялись самые тяжелые авто-тесты.
Z>Без QA на тасках смысл предлагаемой схемы теряется полностью. Мне казалось это очевидно, таски вливаются на стейдж именно для гранулярного тестирования.
Таски тестируются уже слитыми в один бранч во время аппрува релиза. Потому что релиз релизит либо всё, либо ничего (если происходит роллбак). Неясно в чём преимущество тестирования по отдельности, если в проде будет целое.

Z>·>Больше, чем любой другой sha1. Просто по определению.
Z>Верится с трудом, но чем черт не шутит. Напиши примерный процесс со сроками типа:
Z>- день 1. hash1 пошел в релиз, там 90 непротестированнных задач.
Т.е., несколько сотен коммитов!

Z>- день 2. QA протестировали функционал 25 из 90 задач, нашли 3 крита и 1 замечание. Они будут взяты в работу 4 программистами.
Z>- день 3. у нас в релизе 4 новых мерджа, последний комит называется hash2
Четыре коммита! Их можно аккуратно проверить вручную и исследовать ипакт, дав указания QA какой функционал нужно перетестировать.

Z>- ....
Z>Вот тут мне хочется понять, как работает дальше твоя команда из десятков программистов и десятков QA. Через сколько времени появляется последний hash и по какому определению он тестируется дольше первого.
При таком кол-ве задач их можно тестировать в процессе спринта. Большинство критов будет пофикшено в девелопе в течение спринта. В конце спринта создаётся таг и прогоняются тесты ещё раз на теге.

Z>·>Чисто теоретически, результаты любых проверок для sha1 X нельзя проецировать на другой sha1 Y.
Z>Главное не забудь про это, когда будешь описывать процесс выше.
Самое большое я видел около десятка коммитов в релиз-ветке, при этом не особо больших. Обычно меньше 3.