Как устроен процесс деплоймента и delivery в компании

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

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

Как отвечать

Проведите изменение от мержа до прода и на каждом шаге назовите инструмент:

• проверки: go vet, golangci-lint, go test -race ./..., интеграционные тесты с базой в Testcontainers или docker compose;
• сборка: Go собирает статический бинарник, с CGO_ENABLED=0 он не зависит от libc. Отсюда multi-stage Dockerfile и финальный образ на distroless или scratch;
• артефакт: образ тегируется SHA коммита и собирается один раз для всех сред, версия вшивается через -ldflags "-X main.version=...";
• выкатка: Kubernetes с rolling update через Helm или ArgoCD, миграции отдельным шагом до выкатки;
• остановка: сервис ловит SIGTERM через signal.NotifyContext, ждёт снятия с балансировки и вызывает http.Server.Shutdown(ctx), который дорабатывает активные запросы;
• после выкатки: метрики в Prometheus, алерты, канарейка или feature flag для рискованного, откат на предыдущий тег.

Разведите термины: continuous delivery значит, что любой коммит в main готов к выкатке, но решение может принимать человек; continuous deployment выкатывает без ручного шага.

Если спрашиваете вы, узнайте, сколько проходит от мержа до прода, кто может нажать деплой, как часто релизы и как устроен откат.

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

Перечисляют Git, Docker, Kubernetes, Jenkins через запятую. Интервьюер слышит список технологий, а не процесс, и сразу спрашивает, что конкретно делали вы.

Путают delivery и deployment или называют CD просто «автодеплоем».

Забывают про graceful shutdown. Без него rolling update рвёт активные запросы, и каждый релиз даёт всплеск 502 на балансировщике.