Писал ли скрипты для деплоя?

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

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

Как отвечать

Опишите конвейер, который делали или поддерживали, по шагам. Что стоит упомянуть:

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

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

Рассказывают шаблон с придуманной экономией времени и ни одной технической детали. Спрашивают про скрипты, значит ждут перечисления шагов и объяснения, почему они идут именно в таком порядке.

Второе: игнорируют кеш и очерёдность файлов. Закешированный index.html держит пользователей на прошлой сборке, а ассеты, приехавшие после разметки, роняют часть сессий на подгрузке чанков. Обе аварии выглядят как плавающий баг фронтенда.

Третье: кладут ключи в публичные переменные сборки. Всё, что попадает в бандл, читается из браузера, и такой ключ считается скомпрометированным с момента релиза. Секреты остаются в настройках сборки и на стороне сервера.