Как локализовать дефект, если обновление на сайте не отображается, хотя коммит прошел успешно

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

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

Как отвечать

Покажите, что коммит это только начало пути. Между ним и пользователем стоят сборка, деплой, серверы, CDN и браузер, и дефект живёт на одном из звеньев. Идите по порядку:

• что закоммичено: коммит в нужной ветке, PR смержен, изменение попало в ту ветку, из которой собирается окружение;
• прошли ли сборка и деплой: в CI важен не только зелёный статус, но и то, что шаг деплоя реально выполнился, а не пропущен по условию. Сверьте хэш коммита или номер сборки с тем, что отдаёт сервер: многие проекты показывают версию на /version, /health или в футере;
• какое окружение вы смотрите: стенд, прод, нужный регион. Частая причина: изменение выкатили на staging, а смотрят прод;
• кэш: в DevTools на вкладке Network включите Disable cache, посмотрите Cache-Control, Age, ETag и заголовок попадания в кэш у CDN. Проверьте, сменились ли хэши в именах бандлов: если закэширован index.html, браузер тянет старые скрипты. Загляните и в Service Worker на вкладке Application;
• флаги и конфиг: изменение может прятаться за feature flag или зависеть от переменной окружения, которую не завели;
• данные: код новый, но страница рисует контент из базы или CMS, где ничего не поменялось.

Результат каждого шага фиксируйте. Тогда в баг-репорте будет не «не работает», а «на проде отдаётся сборка 1482, последний коммит в 1490, джоба деплоя пропущена».

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

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

Не проверяют, какая версия реально задеплоена, и тратят время на логи приложения, которое ещё не обновилось.

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