CI/CD — не «у нас есть Jenkins», а свойство процесса: каждый коммит проходит один и тот же автоматический путь от изменения до прода, и человек в этом пути принимает решения, а не выполняет шаги. Эта статья — принципы, по которым конвейер строится; конкретика для Java — в соседней, стратегии выкатки — дальше.
Анатомия конвейера
commit → build → fast checks → slow checks → artifact → deploy staging → verify → deploy prod
компиляция unit, линт integration образ авто smoke по стратегии
Имена стадий вторичны; первичны контракты между ними: каждая стадия либо пропускает дальше, либо останавливает — частично-зелёного не существует.
Принцип 1. Артефакт собирается один раз
Build once, deploy many: образ собирается единожды на коммит и тот же самый байт-в-байт артефакт едет в staging и прод. Пересборка «для прода» — лотерея: другие версии зависимостей, другой контекст — протестирован был не тот артефакт, что задеплоен. Технически это образ с тегом-SHA; различия сред — только в конфигурации снаружи (ConfigMap/Secrets, Spring-профили).
Принцип 2. Быстрое — раньше медленного
Fail fast в применении к конвейеру: компиляция и unit-тесты (минуты) — до интеграционных (десятки минут) — до деплоя на staging. Чем раньше падает сломанное, тем дешевле обратная связь. Отсюда же бюджет времени: конвейер до «можно деплоить» дольше ~15 минут перестаёт использоваться как обратная связь — разработчики начинают пушить «пачками», и смысл CI испаряется. Время конвейера — метрика, за которой следят, как за латентностью прода.
Принцип 3. Pipeline as code
Конвейер описан файлом в репозитории (.github/workflows/, .gitlab-ci.yml, Jenkinsfile) — ревьюится, версионируется и откатывается вместе с кодом. Конвейер, настроенный кликами в UI, разделяет судьбу ручных правок кластера: никто не знает, как он устроен, и никто не может его воспроизвести.
Принцип 4. Зелёный main — священен
Сломанный main блокирует всю команду: никто не может ни собраться, ни задеплоиться. Отсюда дисциплина: main защищён (прямые пуши закрыты), PR мержится только зелёным, красный main чинится немедленно и в приоритете — revert быстрее расследования, расследование после. Команда, у которой main красный днями, не имеет CI — у неё есть сервер, который красиво показывает, что всё сломано.
Принцип 5. Деплой ≠ релиз
Деплой — техническое действие (новый код в проде); релиз — продуктовое (функция доступна пользователям). Их разделение — feature flags — снимает главный страх частых деплоев: код едет в прод выключенным, включается отдельно, выключается без отката. Следствие: деплоить можно (и нужно) часто и скучно; релизить — когда готов продукт.
Принцип 6. Окружения — одинаковые и одноразовые
Staging отличается от прода конфигом и объёмом данных — не версиями, не схемой деплоя, не «там docker, тут руками». Чем больше отличий, тем меньше staging проверяет. Идеал — окружение, поднимаемое из деклараций (GitOps): его можно пересоздать, а значит, ему можно верить.
Принцип 7. Конвейер — это тоже прод
У конвейера есть доступность (CI лежит — команда стоит), секреты (и их гигиена), время выполнения и стоимость. Он мониторится, его инциденты разбираются. Отношение «CI — это где-то там у девопсов» заканчивается днём, когда релиз с критическим фиксом не может выехать.
Антипаттерны
| Антипаттерн | Чем кончается | Что взамен |
|---|---|---|
| Пересборка артефакта для прода | Задеплоено не то, что тестировалось | Build once: образ с SHA-тегом |
| Конвейер 40+ минут | Пуши пачками, CI как формальность | Бюджет 15 мин; параллелизм, кеши |
| Pipeline кликами в UI | Невоспроизводимый, неревьюируемый | Pipeline as code в репозитории |
| Красный main «потом починим» | Команда блокирована, тесты игнорируются | Revert немедленно, fix отдельно |
| Релиз = деплой | Страх деплоев, релизные окна по ночам | Feature flags: деплой часто, релиз осознанно |
| Staging «почти как прод» | Проверяется не то, что поедет | Одинаковые декларации, разный конфиг |
| Ручные шаги между стадиями | «Забыл накатить миграцию» | Автоматизация всего пути; человек решает, не выполняет |
Что почитать дальше
- CI для Java/Spring — стадии и quality gates конкретно для нашего стека.
- Стратегии релиза — что происходит после «deploy prod».
- Ветки и релизный цикл — workflow, который кормит этот конвейер.
- Деплой в Kubernetes — куда конвейер доставляет.