Как выглядел процесс деплоя приложения
Что проверяют
Видели ли вы путь кода от мержа до прода своими глазами или только нажимали кнопку. Интервьюеру важны три вещи: что автоматизировано, как выкатывают без простоя и как откатываются. Следом обычно спрашивают, как вместе с релизом менялась схема базы.
Как отвечать
Рассказывайте про свой реальный конвейер по шагам, называя инструменты:
- сборка: CI (GitLab CI, Jenkins, GitHub Actions) на каждый мерж запускает
mvn verifyили./gradlew build. Фазаpackageв Maven уже включаетtest, отдельный прогон тестов после неё не нужен; - артефакт: jar Spring Boot упаковывается в Docker-образ через многослойный
Dockerfile, Jib илиspring-boot:build-image, образ получает тег с версией или хэшем коммита и уходит в registry; - выкатка: чаще всего Kubernetes с Helm-чартами или Argo CD, стратегия rolling update. Трафик на новый под идёт только после readiness-пробы, у Spring Boot это
/actuator/health/readiness; - миграции: Flyway или Liquibase при старте приложения или отдельной джобой. Схема меняется обратно совместимо, чтобы старая и новая версии жили одновременно;
- конфигурация и секреты: профили, переменные окружения, Vault или Kubernetes Secrets, а не пароли в
application.ymlв репозитории; - откат:
helm rollbackилиkubectl rollout undoдо предыдущей ревизии, плюс наблюдение за ошибками и латентностью после релиза в Prometheus и Grafana.
Если у вас был ручной деплой или WAR на Tomcat, так и говорите, и добавьте, что именно автоматизировали бы первым. Это честнее и сильнее, чем пересказ чужой идеальной схемы.
Где спотыкаются
Описывают схему из статьи и тонут на первом уточнении: сколько длился пайплайн, кто нажимал кнопку на прод, что происходило при красных тестах.
Не думают о миграциях при откате. Если релиз удалил колонку, rollout undo вернёт старый код, который её ждёт, и откат превратится во вторую аварию.
Забывают про graceful shutdown: без server.shutdown=graceful и корректной readiness-пробы при rolling update часть запросов обрывается, и деплой «без простоя» на деле даёт всплеск 502.