Есть ли ручные действия при развертывании изменений
Что проверяют
Знаете ли вы, как изменения на вашем проекте попадают на тестовые стенды и в прод, и какую роль в этом играет QA. По ответу видно, понимаете ли вы, где в процессе живут риски. Следом обычно спрашивают, что вы проверяете сразу после выкладки и как понять, что пора откатываться.
Как отвечать
Опишите конвейер своего проекта по шагам и отметьте, какие из них ручные и почему:
- сборка и автотесты: пайплайн в GitLab CI, Jenkins или GitHub Actions, на каждый merge request гоняются юнит-тесты и линтеры, на стенд уходит собранный артефакт;
- выкладка на стенд: автоматически после слияния или по кнопке, есть ли отдельные стенды под фичи;
- ручной гейт перед продом: кнопка запуска прод-джобы или аппрув релиза, нормальная и осознанная ручная точка;
- миграции и конфиги: применяются пайплайном или администратор делает их руками;
- фиче-флаги: включение функции отдельно от деплоя, часто на процент пользователей;
- проверки после выкладки: смоук на проде, сверка версии сборки, просмотр ошибок в Sentry и графиков в Grafana.
Дальше покажите, что различаете оправданные ручные шаги и опасные. Аппрув релиза, исследовательское тестирование и решение о включении флага осознанно оставляют людям. А ручное копирование файлов на сервер, правка конфига прямо на машине или SQL-скрипт, который кто-то запускает по памяти, это прямой источник инцидентов. Хороший пример из опыта: какой ручной шаг однажды забыли и как вы его автоматизировали или внесли в чек-лист релиза.
Если сами деплой не видели, честно скажите, что его делали DevOps, и опишите, что знаете: на каком этапе вы получали сборку, как узнавали номер версии, кто откатывал.
Где спотыкаются
Отвечают «всё автоматически» и не могут назвать ни одного шага пайплайна. Это воспринимается как незнание процесса.
Путают ручное тестирование с ручным развертыванием и уходят в рассказ про регресс.
Не знают, как на проекте откатывают релиз и кто принимает это решение, хотя QA часто первым видит, что что-то пошло не так.