Опишите процесс развертывания приложения от кода до продакшена

Что проверяют

Понимаете ли вы конвейер целиком и знаете ли, где в нём стоят проверки качества и что именно блокирует выпуск. Для тестировщика это вопрос не про инструменты, а про то, в каких точках вы влияете на решение выпускать или нет.

Как отвечать

Пройдите по шагам и на каждом называйте проверку:

• ветка и запрос на слияние: линтер, юнит-тесты, сборка, статический анализ, ревью;
• сборка артефакта: образ собирается один раз и помечается версией коммита;
• продвижение: один и тот же артефакт едет по окружениям, настройки приходят переменными окружения, секреты из хранилища;
• миграции базы: применяются отдельным шагом и совместимо, чтобы старая и новая версия какое-то время жили вместе;
• тестовое окружение: автотесты на API и интерфейсе плюс исследовательское тестирование рискованных мест;
• решение о выпуске: кто подтверждает и какой набор проверок обязателен;
• прод: выкат по выбранной стратегии, флаги функциональности, чтобы выпуск и включение были разными событиями;
• после выката: короткий проверочный прогон, мониторинг, алерты, готовый откат.

Если в вашей команде конвейер проще, так и скажите, объяснив, чего в нём нет и почему это терпимо. Осознанный простой процесс выглядит лучше, чем пересказ чужого сложного.

Где спотыкаются

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

Собирают артефакт заново на каждом окружении. Тогда на проде оказывается не то, что проверяли, и разбор любого дефекта начинается с вопроса, та ли это сборка.

Забывают про базу и откат. Код вернуть легко, схему нет: миграция, удалившая колонку, ломает предыдущую версию сразу после отката, поэтому удаление выносят в отдельный релиз.