Как происходит релиз

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

Понимаете ли вы путь коммита до продакшена в Java-проекте и где на этом пути всё ломается. Следом обычно спрашивают про откат: как вернуть прошлую версию, если Flyway уже накатил миграцию.

Как отвечать

Опишите процесс своей команды по этапам и с инструментами:

• версия: в Maven разделены SNAPSHOT и релизные версии, релизная неизменяема. Её ставит CI по git-тегу или maven-release-plugin, в Gradle обычно плагин версионирования по тегам;
• сборка и проверки: mvn verify или ./gradlew check гоняют модульные и интеграционные тесты (часто на Testcontainers), статический анализ, проверку уязвимых зависимостей;
• образ: Jib или spring-boot:build-image собирают образ без ручного Dockerfile. Один образ продвигается по окружениям, конфигурация приходит снаружи;
• миграции: Flyway или Liquibase при старте приложения. Схему меняют в два шага (expand/contract): сначала добавляют колонку и пишут в обе, через релиз удаляют старую;
• выкатка: rolling update в Kubernetes с readiness-пробой Spring Boot Actuator (/actuator/health/readiness) и server.shutdown=graceful, чтобы под дождался текущих запросов. Для рискованных изменений canary или blue-green, для незаконченных фич флаги;
• после релиза: метрики Micrometer в Prometheus и Grafana, алерты на ошибки и задержки, откат по заранее оговорённому порогу.

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

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

Описывают релиз как «мерж в main, дальше DevOps». Для мидла и выше это слабо: от вас ждут понимания, что происходит с приложением при выкатке.

Пересобирают артефакт под каждое окружение. Тогда на прод едет не тот бинарь, который тестировали.

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