Что проверяется при отводе мерджей или релиз кандидатов в релизную ветку
Что проверяют
Понимаете ли вы, что в релизную ветку попадает не только код, и умеете ли смотреть на состав изменений, а не только на набор проверок. Вопрос про процесс: кто и по каким признакам решает, что кандидат в релиз годится.
Как отвечать
Разделите сам отвод ветки и последующие вливания в неё.
При отводе проверяется состав: список изменений сверяется с задачами, попавшими в релиз, лишнего быть не должно. По журналу коммитов и различиям с основной веткой смотрят на отладочные включения, оставленные заглушки, состояние флагов возможностей по умолчанию, наличие и обратимость миграций, версию и заметки о выпуске. Сборка должна собираться из самой ветки, а артефакт нести идентификатор коммита, из которого сделан.
Дальше на собранном кандидате гоняют дымовой прогон, регресс по затронутым областям и по критичному пути, обновление поверх предыдущей версии с реальными данными, совместимость контрактов со смежными сервисами, репетицию миграции и отката на копии боевой базы.
Каждое вливание правки в ветку проверяется отдельно: правка минимальна, она же есть в основной ветке, артефакт пересобран, дымовой прогон повторён. Критерии выпуска назовите явно: нет открытых блокеров, известные дефекты описаны, план отката проверен, ответственный за решение известен.
Где спотыкаются
Тестируют одну сборку, а выкатывают другую. После вечернего вливания исправления кандидат стал новым, а результаты прогона остались от старого. Любой коммит в ветку обнуляет часть проверок, и решать, каких именно, надо осознанно.
Второе: чинят только релизную ветку. Правка, не вернувшаяся в основную, всплывает обратно уже как дефект следующего выпуска, и происхождение такого возврата ищут потом неделями.
Третье: проверяют только новые возможности. Ломается обычно стык независимо влитых изменений, миграция данных и обновление поверх старой версии, а не сама возможность, которую разработчик только что проверил сам.