Как устроен процесс пуша кода и автоматической раскатки на тестовую среду?

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

Знаете ли вы, что происходит между git push и работающим сервисом на тестовом стенде, и можете ли назвать конкретные шаги и инструменты своего проекта. Уточнения обычно такие: где хранится конфигурация для разных сред и как миграции базы уживаются с несколькими ветками на одном стенде.

Как отвечать

Проведите изменение по конвейеру:

• триггер: пуш или открытие merge request запускает пайплайн по вебхуку. Описание живёт в репозитории: .gitlab-ci.yml, Jenkinsfile или workflow GitHub Actions;
• сборка и тесты: mvn verify или ./gradlew build. Unit-тесты на JUnit 5 гоняет Surefire, интеграционные Failsafe, базу и брокер поднимает Testcontainers. Кеш ~/.m2 или Gradle экономит минуты;
• качество: SonarQube с quality gate, Checkstyle или SpotBugs, проверка зависимостей на уязвимости. Упавший шаг блокирует мерж;
• артефакт: Docker-образ через Jib или spring-boot:build-image, тег по SHA коммита, пуш в registry. Образ собирается один раз и переезжает между средами, а различия задаются переменными окружения и профилями Spring;
• раскатка: Helm или GitOps через ArgoCD, где CI меняет тег образа в репозитории манифестов, а Argo синхронизирует кластер. Бывают и динамические стенды на каждый MR;
• миграции и проверка: Flyway или Liquibase при старте или отдельной задачей, readiness через /actuator/health/readiness, после выкатки смоук-тесты и автотесты QA.

Расскажите, сколько идёт пайплайн в вашем проекте и какой шаг самый долгий: это честный показатель, что вы с ним работали.

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

Пересобирают артефакт под каждую среду. Тогда на проде оказывается не тот бинарник, что прошёл тесты.

Тегируют образ как latest. Непонятно, какая версия стоит на стенде, а манифест не меняется, и Kubernetes не видит повода перезапустить поды.

Не думают про общую тестовую базу. Две ветки с разными миграциями под одним номером версии ломают старт приложения: Flyway находит несовпадение checksum и отказывается мигрировать.