Как часто выкатывались обновления

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

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

Как отвечать

Начните с честной цифры из своего опыта: несколько раз в день, раз в спринт или раз в месяц по согласованию. Любая частота нормальна, если вы объясните, чем она ограничивалась. Дальше опишите путь изменения, для Go-сервиса он обычно такой:

• проверки: go vet, golangci-lint, go test -race на каждом мерж-реквесте, интеграционные тесты с настоящей базой через testcontainers;
• сборка: статический бинарник в многоэтапном Dockerfile, итоговый образ на distroless или scratch, тег по коммиту;
• выкатка: rolling update в Kubernetes с readiness-пробой, для рискованных изменений канарейка или feature flags;
• остановка: сервис ловит SIGTERM через signal.NotifyContext, перестаёт принимать запросы и дожидается текущих через http.Server.Shutdown. Kubernetes по умолчанию ждёт 30 секунд, потом шлёт SIGKILL;
• миграции: обратно совместимые, в две выкатки: сначала добавить колонку и писать в обе, потом убрать старую.

Если есть метрики, назовите их языком DORA: частота деплоев, время от коммита до прода, доля неудачных выкаток, время восстановления. Только свои реальные цифры: придуманные проценты разваливаются на первом уточнении.

Если выкатки были редкими и ручными, так и скажите, и добавьте, что мешало и что вы бы поменяли. Это сильнее, чем приукрашенная картина.

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

Называют частоту и не могут рассказать, как откатывали. Откат образа занимает минуту, а откат миграции без плана может занять ночь.

Не знают, что происходит с запросами при выкатке. Без graceful shutdown каждый деплой обрывает часть запросов, и частые релизы превращаются в частые ошибки.

Путают CI и CD: «у нас был Jenkins» ещё не означает, что изменения доезжали до прода автоматически.