Приходилось ли настраивать системы деплоя и какие

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

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

Как отвечать

Опишите маршрут от коммита до прода своими словами. Для Go он обычно такой: пайплайн прогоняет линтер и go test с детектором гонок, собирает образ многостадийным Dockerfile с CGO_ENABLED=0, кладёт статический бинарник в минимальный базовый образ и тегирует по хешу коммита, а не меткой latest. Дальше раскладка в Kubernetes через шаблоны или через подход, где желаемое состояние кластера описано в репозитории.

Назовите то, что отличает человека с опытом:

• стратегия выкатки: постепенная замена подов, канареечная доля трафика, откат на предыдущий тег;
• пробы готовности и живости, чтобы трафик не шёл в неготовый под;
• корректное завершение: по сигналу сервис перестаёт принимать новое и дорабатывает текущее через server.Shutdown(ctx);
• миграции базы отдельным шагом и всегда совместимые со старой версией кода;
• секреты не в образе, а в хранилище секретов.

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

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

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

Собирают образ на сервере или катят плавающий тег. Артефакт перестаёт быть воспроизводимым, и на вопрос, что именно сейчас работает на проде, точного ответа уже нет.