Как устроены внутренние пайплайны и процесс выкатывания релизов

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

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

Как отвечать

Пройдите по стадиям конвейера своего проекта:

• сборка и проверки: Maven или Gradle, юнит-тесты на JUnit 5, интеграционные на Testcontainers с настоящей базой, статический анализ SonarQube, Checkstyle или SpotBugs. Всё это запускается на каждый merge request в GitLab CI, Jenkins, TeamCity или GitHub Actions;
• артефакт: jar публикуется в Nexus или Artifactory, Docker-образ собирается через Jib или spring-boot:build-image и помечается версией или хэшем коммита. Один и тот же образ едет по всем окружениям, отдельной сборки под прод нет;
• окружения и выкатка: dev, stage, прод. Деплой в Kubernetes через Helm или Argo CD по модели GitOps. Стратегия по умолчанию rolling update, для рискованных изменений canary или blue-green, для незаконченных фич флаги;
• здоровье и откат: readiness и liveness пробы на Spring Boot Actuator (/actuator/health/readiness), метрики и алерты после выкатки, откат на предыдущий образ одной командой;
• миграции: Flyway или Liquibase. Изменения схемы делают обратно совместимыми в две фазы (expand и contract), потому что при rolling update старая и новая версии работают с одной базой одновременно.

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

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

Называют набор инструментов без последовательности: «Jenkins, Docker, Kubernetes». Интервьюеру важнее, какие проверки стоят на пути в прод и кто принимает решение о выкатке.

Приводят красивый процент вроде «ускорили релизы на 30%», но не могут объяснить, как его посчитали. Лучше честные цифры до и после или вовсе без цифр.

Не думают о базе при rolling update: переименование колонки одной миграцией ломает поды старой версии, которые ещё обслуживают трафик.