Как был организован релизный цикл

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

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

Как отвечать

Вопрос об опыте, поэтому рассказывайте про реальный проект по этапам:

• ветки и частота: trunk-based с короткими ветками или GitFlow с релизными, как часто выходили релизы, кто решал, что уходит;
• CI: go vet, golangci-lint, go test -race, статический бинарник с CGO_ENABLED=0, многоэтапный Dockerfile, сканирование образа, версия через -ldflags "-X main.version=...";
• версии: семантические теги вида v1.8.0. Для библиотек важно, что со второй мажорной версии путь модуля получает суффикс /v2;
• выкатка: стейдж, затем прод. Rolling update в Kubernetes, канарейка или blue-green, фича-флаги для незаконченного. Сервис по SIGTERM дожидается текущих запросов через http.Server.Shutdown;
• миграции: goose или golang-migrate, только обратно совместимые изменения, чтобы старая и новая версии работали на одной схеме во время выкатки;
• после релиза: метрики и алерты, критерий отката, путь для hotfix.

Цифры нужны свои: как часто релизились, сколько шёл код от мержа до прода, сколько откатов было за квартал. Хорошо звучит и то, что вы бы изменили, например ручное согласование, которое тормозило выкатку.

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

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

Отвечают набором слов: Agile, спринты, CI/CD, Kubernetes. Интервьюер ждёт механику: что происходит после мержа и кто нажимает кнопку.

Приводят круглые проценты вроде «ускорили релизы на 30%» без понимания, как это мерили. Первый же уточняющий вопрос это вскроет.

Не могут объяснить откат. Откатить образ просто, а миграцию, которая удалила колонку, нельзя, поэтому схему меняют в несколько релизов.