Как понять, что код попал в релиз и успешно внедрен

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

Доводите ли вы задачу до пользователя или считаете её сделанной после мержа. Вопрос поведенческий, поэтому интервьюер ждёт ваш реальный процесс и пример, когда «задеплоено» разошлось с «работает». Следом спрашивают, как вы поймёте, что релиз навредил, и что сделаете дальше.

Как отвечать

Разделите ответ на два вопроса: код доехал до пользователя и код работает как задумано.

Доехал:

• связка коммита и сборки: пайплайн в GitHub Actions или GitLab CI показывает, какой коммит собран и на какое окружение выложен;
• версия в сборке: хэш коммита, вшитый при сборке и доступный в meta-теге или в /version.json. На проде можно открыть страницу и проверить, какая версия загружена;
• кэш: у бандлов хэш в имени файла, а index.html не должен надолго кэшироваться на CDN. Если есть service worker, пользователь может сидеть на старой версии до перезагрузки вкладки;
• фича-флаги: код может быть в релизе, но выключен. Проверьте, что флаг включён для нужной аудитории.

Работает:

• ошибки: в Sentry релиз помечается версией, новые ошибки видно в разрезе релиза, а загруженные source maps дают читаемый стек;
• производительность: Core Web Vitals с реальных пользователей, прежде всего LCP, INP и CLS, до и после выкладки;
• продуктовая метрика: конверсия той кнопки или формы, ради которой делалась задача.

Расскажите свою историю с цифрами: как быстро заметили проблему, сколько заняли откат или фикс. Если выкладкой занимались другие люди, скажите честно и опишите, что проверяли сами после релиза.

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

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

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

Не знают, как откатиться. Ответ сильнее, когда вы называете способ: выкладка предыдущего артефакта, выключение флага, откат на CDN.