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

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

Различаете ли вы «код влит в ветку», «код задеплоен» и «фича включена для пользователей». Это три разных состояния, и интервьюер хочет услышать, как вы проверяете каждое. Следом обычно спрашивают про фича-флаги.

Как отвечать

Проследите цепочку от задачи до пользователя:

• мерж: пул-реквест связан с задачей и влит в релизную ветку. Попал ли коммит в релиз, покажет git tag --contains <sha> или список изменений релиза;
• деплой: какая версия сейчас на проде. Надёжнее всего эндпоинт вроде /version или /health, который отдаёт номер сборки и хеш коммита, либо экран «О приложении» в мобильном клиенте. Сверяйте с содержимым релиза, а не с обещаниями;
• включение: код может быть на проде, но за выключенным флагом или раскатан на 5% пользователей. Уточните состояние флага и сегмент, в который попадает ваш тестовый аккаунт;
• работа: короткий смоук основного сценария фичи на проде тестовыми аккаунтами, без действий с реальными деньгами и данными клиентов;
• наблюдение: ошибки в мониторинге с тегом релиза, графики ошибок и времени ответа, события аналитики по новой фиче. Если событие не приходит совсем, фичу, скорее всего, никто не видит.

У мобильных своя специфика: сборка проходит ревью магазина, раскатка идёт поэтапно, у части пользователей ещё старая версия. В вебе помните про кеш CDN и старый JS-бандл в браузере: «у меня не работает» иногда значит «у меня прошлая версия».

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

Видят в трекере статус «Done» и считают фичу выпущенной. Статус меняет человек, а не деплой.

Не знают про фича-флаги и заводят баг «на проде не работает», хотя фичу ещё не включили. Или наоборот, проверяют под внутренним аккаунтом с включённым флагом и не замечают, что у обычных пользователей фичи нет.

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