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

·>Вот тут "стартуем ветку от release, вливаем в develop" — прежде чем влить в девелоп, надо с ним замержиться

Не надо так делать. Вливать мастер в релиз у нас нельзя, соответственно и в ветки его никто не вливает. Если делать как ты предлагаешь, весь смысл схемы теряется сразу.

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

Что за проект такой, что конфликты вливания дело настолько частое и нетривиальное? В таком проекте я крайне не рекомендую флоу с двойным вливанием.

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

Ну да, в гитфлоу мердж один. Ты как будто только что обнаружил, что в моей схеме два мерджа на одну таску, хотя об этом сразу было сказано.

·>Почти. Только "потом начинается тестирование всего" — это QA полной интерации всего и вся, а не конкретной таски.

Ты уклоняешься от описания процесса тестирования тасок и заявляешь о том, что это должны делать юниттесты. Описываемая схема именно для тестирования тасок.

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

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

·>Больше, чем любой другой sha1. Просто по определению.

Верится с трудом, но чем черт не шутит. Напиши примерный процесс со сроками типа:
— день 1. hash1 пошел в релиз, там 90 непротестированнных задач.
— день 2. QA протестировали функционал 25 из 90 задач, нашли 3 крита и 1 замечание. Они будут взяты в работу 4 программистами.
— день 3. у нас в релизе 4 новых мерджа, последний комит называется hash2
— ....

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

·>Чисто теоретически, результаты любых проверок для sha1 X нельзя проецировать на другой sha1 Y.

Главное не забудь про это, когда будешь описывать процесс выше.