Кто занимается выкаткой в CI/CD

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

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

Как отвечать

Начните с распределения ролей, которое реально встречается:

• фронтенд-разработчики: пишут и правят конфиг пайплайна (.gitlab-ci.yml, workflow в GitHub Actions), шаги линтера, тестов и сборки;
• DevOps или платформенная команда: раннеры, кластер, CDN, секреты, шаблоны пайплайнов, которые команды подключают у себя;
• релиз-менеджер или тимлид: запускает ручной шаг выкатки на прод, если он не автоматический.

Дальше покажите, что знаете специфику фронтенда. Статическая сборка обычно уезжает в объектное хранилище за CDN или в образ с nginx. Файлы с хэшем в имени кэшируются надолго, а index.html отдаётся без долгого кэша, иначе пользователи получат старую страницу со ссылками на удалённые чанки. Переменные окружения для клиента вклеиваются на этапе сборки, поэтому один артефакт на все стенды получается только через конфиг, который грузится в рантайме. Для просмотра веток часто поднимают превью-стенды на каждый merge request.

Упомяните откат: переключение на прошлую версию артефакта или повторный деплой прошлого тега, а не срочный revert с новой сборкой. Хороший плюс: выгрузка source maps в систему мониторинга ошибок вроде Sentry, а не на публичный сервер.

Если пайплайн у вас целиком вёл DevOps, скажите об этом прямо и назовите, что вы в нём понимали и что правили сами.

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

Отвечают «выкаткой занимается DevOps» и на этом останавливаются. Интервьюер слышит, что вы не отвечаете за то, как ваш код попадает к пользователю.

Не знают про кэширование index.html и не могут объяснить, почему после релиза у части пользователей падает загрузка чанков.

Путают непрерывную доставку и непрерывное развёртывание. В первом случае прод выкатывается кнопкой, во втором каждый зелёный мерж уходит в прод сам.