← назад к разделу

Принципы конвейера одинаковы для любого стека; эта статья — их приземление на Java/Spring: какие стадии, в каком порядке, что блокирует merge и как уложиться в бюджет 15 минут.

Стадии для Spring-сервиса

1. compile + unit        ~2-4 мин   ворота PR
2. static checks         ~2-3 мин   параллельно с (1)
3. integration tests     ~5-10 мин  Testcontainers: PG + WireMock
4. build image + push    ~2 мин     после зелёных (1)-(3)
5. deploy staging        автоматом из main

Порядок — по цене обратной связи: дешёвое и быстрое раньше. Стадии 1–2 параллелятся; интеграционные — самая дорогая часть, и за её временем следят отдельно.

Сборка: кеши решают

Холодная Gradle-сборка Spring-проекта — минуты только на скачивание зависимостей. Лечится кешированием на уровне CI: кеш Gradle (~/.gradle/caches) между прогонами, кеш слоёв Docker-образа (зависимости меняются редко — многослойная сборка переиспользует слой с ними), при monorepo — Gradle build cache. Конвейер без кешей платит за одно и то же на каждый коммит; разница — кратная.

Тесты: слои в конвейере

Раскладка по тестовой стратегии: unit — без Spring-контекста, секунды, бегут при каждом PR первыми; интеграционные — Spring-контекст + Testcontainers (PostgreSQL, WireMock для внешних HTTP; без Kafka в базовом классе) — главная проверка сервиса. На CI Testcontainers работает через Docker-демон раннера; контейнеры переиспользуются в рамках прогона (@Container static), а не поднимаются на каждый класс.

Два правила, которые держат конвейер живым. Флаки-тесты лечатся, а не ретраятся: auto-retry прячет настоящие гонки и приучает не верить красному; мигающий тест — баг с приоритетом (systematic-разбор, не «перезапусти»). Тесты не ходят наружу: интеграционный тест, зовущий реальный staging-сервис или интернет, падает от чужих причин — всё внешнее замокано WireMock-ом или поднято контейнером.

Quality gates: что блокирует merge

Прямо из Security Style Guide — инструменты, которые в CI работают воротами, а не отчётами:

GateИнструментБлокирует
Компиляция с обработкой предупрежденийError ProneДа
Статический анализ баговSpotBugs + FindSecBugsДа, по severity
Уязвимые зависимостиOWASP Dependency-Check / RenovateДа, по CVSS-порогу
Секреты в кодеGitleaksДа, безусловно
Образ и базаTrivyДа, по severity
Опасные миграцииРевью DDLДа — каждая миграция

Принципиально: gate либо блокирует, либо его нет. «Отчёт SAST, который никто не открывает» — это нагрузка на CI без эффекта; правило с suppression-ами по сроку и обоснованию (R-SEC-правила) — работает. Стилевые споры в gates не входят — они решаются стандартом и AI-ревью, а не линтером в конвейере.

Артефакт: образ и его метаданные

Финал CI — образ: тег = SHA коммита, манифест с метаданными (версия, коммит, время сборки — Spring Boot кладёт это в /actuator/info через springBoot { buildInfo() }). Образ подписывается/сканируется по требованиям организации и пушится в registry — дальше начинается зона CD. Jar-в-артефактах-CI как способ доставки — прошлая эпоха: деплой-юнит — образ.

Время конвейера: бюджет и борьба

Когда конвейер выползает за бюджет, чинят в порядке отдачи: кеши (если их нет — всё остальное бессмысленно) → параллельные стадии → параллельные тесты (Gradle maxParallelForks, разбиение интеграционных на шарды) → ревизия самих тестов (10 секунд Thread.sleep в тесте — это 10 секунд на каждом прогоне навсегда; Awaitility-запреты сюда же) → выделенные раннеры, если уперлись в железо.

Антипаттерны

АнтипаттернЧем кончаетсяЧто взамен
Auto-retry флаки-тестовГонки доезжают до продаЧинить; кварантин с тикетом — максимум на спринт
Тесты ходят в staging/интернетКрасное от чужих причин, недоверие к CITestcontainers + WireMock
SAST-отчёт без блокировкиУязвимости копятся «к прочтению»Gate по severity с дисциплиной suppressions
Сборка без кешейКратно медленнее, бюджет сорванКеш Gradle + слои образа
Линтер стиля как gateВойны с форматером в каждом PRСтиль — автоформатом и AI-ревью, не воротами
Интеграционные тесты «по кнопке»Никто не нажимает; ломается молчаВ конвейере каждого PR, в бюджете времени

Что почитать дальше

  • Принципы конвейера — рамка, в которую встроены эти стадии.
  • Test Strategy Style Guide — слои тестов и правила TS-*.
  • Security Style Guide — полный список gates с кодами правил.
  • Стратегии релиза — что происходит с собранным образом дальше.