Кто отвечает за выкатывание релизов

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

Для Go-разработчика вопрос почти никогда не про оргструктуру. Интервьюер проверяет, доводили ли вы свой сервис до продакшена и знаете ли, что код должен уметь, чтобы выкладка прошла без простоя. Следом обычно спрашивают про graceful shutdown и миграции базы.

Как отвечать

Коротко про роли: в большинстве продуктовых команд сервис выкатывает сама команда, по принципу «написал, значит отвечаешь и за работу в проде». Платформенная команда или DevOps дают конвейер: CI, кластер Kubernetes, Helm-чарты, Argo CD. Релиз-менеджер встречается в крупных компаниях и при выпуске по расписанию.

Дальше покажите свою часть, она важнее:

• сборка: статический бинарник с CGO_ENABLED=0, многоэтапный Dockerfile с минимальным образом вроде distroless, версия вшивается через -ldflags "-X main.version=...";
• версии: семантические теги v1.4.2. У библиотек мажорная версия от второй требует суффикса /v2 в пути модуля. Бинарники к релизу удобно собирать GoReleaser;
• пробы: отдельные readiness и liveness эндпоинты, чтобы Kubernetes не слал трафик в неготовый под и перезапускал зависший;
• graceful shutdown: ловим SIGTERM через signal.NotifyContext и дожидаемся текущих запросов через http.Server.Shutdown(ctx) с таймаутом меньше terminationGracePeriodSeconds;
• миграции: обратно совместимые, по схеме «расширить, затем сузить», чтобы старая и новая версии могли работать с базой одновременно во время rolling update;
• откат: предыдущий образ всегда доступен, рискованное закрыто фича-флагом.

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

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

Отвечают «DevOps выкатывает, я пишу код». Для бэкенд-разработчика это звучит как незнание того, как живёт его сервис.

Не обрабатывают SIGTERM. При каждом деплое часть запросов обрывается, и это видно по всплеску ошибок.

Выкатывают вместе с кодом миграцию, которая переименовывает колонку. Пока старые поды работают, они падают на отсутствующей колонке.