CI/CD

Я регулярно вижу конвейеры, настолько медленные и нестабильные, что разработчик успевает переключиться на другую задачу раньше, чем придёт результат. Диаграмма Continuous Delivery тут уже ничего не объясняет. CI/CD — про измеримую скорость обратной связи, неизменяемые артефакты с явным версионированием и системную работу с нестабильными тестами. Это не «инструмент команды DevOps», а платформа, на которой стоят Progressive Delivery, Infrastructure as Code и GitOps. Соседний лист к Programming Languages под L1 Programming / Scripting.

Что должен уметь

Главный навык на уровне L4 — собрать конвейер сервиса с нуля и уложиться в тот срок обратной связи, о котором договорилась команда, глядя не только на среднее, но и на хвост распределения. Это не «прочитать туториал и накидать этапов». Туториалом такое не закрывается. Это понимать кеширование (зависимости, артефакты сборки, слои Docker), параллельность (тесты, разложенные по частям), ранний обрыв на дешёвых этапах — и системно вычищать нестабильные тесты.

Различает CI и CD; работает с конвейером своего сервиса: запускает задачи, читает логи, разбирает падения, перезапускает. Знает стратегию ветвления своей команды.
Пишет автоматические тесты в CI: модульные и интеграционные. Понимает пирамиду тестов (см. Test Strategy).

Собирает конвейер сервиса с нуля: этапы (сборка → тесты → проверка безопасности → выкатка), хранение артефактов (неизменяемые, с осмысленными версиями), продвижение по окружениям. Конвейер описан кодом в репозитории сервиса и проходит ревью через PR.
Работает в trunk-based development: мелкие частые коммиты в main, feature flags для незаконченного, ветка живёт часы или день. Понимает, чем это оплачивается по сравнению с GitFlow.
Безопасно обращается с секретами в конвейере: федерация через OIDC вместо долгоживущих ключей доступа, ограничение области действия, маскирование в логах.

Проектирует CI/CD как платформу команды или организации: общие шаблоны, golden paths для типовых сервисов, подключение сервиса без заявок и посредников.
Разгоняет конвейер: кеширование, параллельность, ранний обрыв, нестабильные тесты в карантин. Целевую длительность выводит из собственных замеров и потребностей команды, а не из универсального числа.
Использует пять текущих метрик DORA как совместный индикатор здоровья: change lead time, deployment frequency, failed deployment recovery time, change fail rate и deployment rework rate.

L6+

Проектирует правила выкатки в крупной организации: ограничения регуляторов (SOX, PCI DSS, GDPR), журнал аудита, подписанные артефакты (Sigstore, cosign), SLSA и SBOM, воспроизводимые сборки. CI/CD превращается в инструмент соответствия требованиям.

Материалы

Книги

Jez Humble, David Farley — Continuous Delivery (Addison-Wesley, 2010). Каноническая книга, которая ввела сам термин. Актуальна по принципам: собрать один раз, артефакт не менять, конвейер описывает поток создания ценности.
Nicole Forsgren, Jez Humble, Gene Kim — Accelerate (IT Revolution, 2018). Эмпирическая основа исходной четырёхметричной модели DORA; актуальный состав метрик сверяется с текущим руководством DORA.
Gene Kim, Jez Humble, Patrick Debois, John Willis — The DevOps Handbook (IT Revolution, 2-е изд., 2021). Прикладное руководство: как внедрять CI/CD в уже существующей организации, с разбором кейсов.

Статьи и доклады

DORA — Software delivery performance metrics. Актуальные определения пяти метрик, границы их применимости и типовые ошибки измерения.
Paul Hammant — trunkbaseddevelopment.com. Полный справочник по trunk-based development; альтернатива GitFlow с обоснованием.
Mike Bland — Goto Fail, Heartbleed, and Unit Testing Culture (martinfowler.com). Почему модульные тесты без культуры их писать бесполезны.
SLSA project — SLSA specification v1.2. Текущие дорожки Build и Source; старая единая шкала от 1 до 4 больше не описывает актуальную спецификацию. См. Supply Chain Security.

Инструменты

GitHub Actions / GitLab CI / Jenkins / CircleCI / Buildkite / Drone — движки выполнения. Выбор обычно тянется за платформой: живёте в GitHub — Actions, свой Git на своих серверах — Jenkins или Drone. Описание конвейера кодом переносится между движками разумными усилиями — это стоит проверять до выбора, а не после.
Sigstore / cosign — подпись артефактов без своих ключей, через короткоживущие сертификаты.
Renovate / Dependabot — автоматическое обновление зависимостей через PR. По моим наблюдениям, в зрелых командах настроен либо один, либо другой: отставание зависимостей превращается в дыры безопасности.
Buildkite Test Engine / Datadog CI Visibility — наблюдаемость самого конвейера: тренды длительности сборки, поиск нестабильных тестов, метрики DORA прямо из конвейера.
trunk.io / pre-commit — сборка линтеров и форматтеров в одну точку. Гоняется локально и в CI; экономит ревью на замечаниях про пробел в конце строки.
Argo Workflows / Tekton — CI/CD, родной для Kubernetes. Имеет смысл, когда сам конвейер — сложный распределённый процесс: обучение моделей, выкатка сразу в несколько кластеров.

Best practices

Актуальное руководство DORA группирует пять метрик в пропускную способность и нестабильность и отдельно предупреждает: не оптимизируйте один показатель и не устраивайте соревнование между командами. Для CI/CD это удобная проверка границ. Изменение в конвейере оценивается не только по частоте выкаток, но и по времени восстановления, доле неудачных изменений и объёму незапланированных переделок.

Дальше три вещи, без которых остальное не держится. Порядок неслучаен.

Первая — скорость и надёжность самого CI. Универсального «десять минут» не существует: команда снимает свою базу, смотрит p50 и p95, договаривается, куда двигаться. Дальше важнее другое. Нестабильный тест не перезапускается до зелёного — он изолируется, получает владельца и срок, потому что иначе перезапуск превращается в способ не видеть, что конвейер сломан.

Вторая — конвейер живёт кодом. Настроенный мышкой в интерфейсе, он невоспроизводим: его нельзя отревьюить, нельзя версионировать вместе с сервисом, нельзя восстановить после ухода человека, который его собирал. .github/workflows/ или Jenkinsfile рядом с кодом дают и ревью через PR, и историю.

Третья — trunk-based development. Ветка, которая живёт три недели, оплачивается адом слияний, и интеграция в ней впервые проверяется прямо перед мержем, то есть в самый неудачный момент. Короткие коммиты в main плюс feature flags — не вкусовщина. Без них progressive delivery не собирается.

Секреты в конвейере — через OIDC, а не долгоживущими токенами. Секрет в GitHub Actions с вечным ключом доступа к AWS — это постоянный вход в прод-аккаунт для всякого, кто вытащит его из логов. Федерация через OIDC выдаёт короткоживущий токен на конкретную задачу, со сроком жизни в минуты, и после неё он мёртв. Поддержка есть везде: GitHub Actions, GitLab CI, CircleCI, Buildkite на стороне CI, AssumeRoleWithWebIdentity и Workload Identity Federation на стороне облаков. На мой взгляд, это самый дешёвый шаг в безопасности цепочки поставок из возможных.

Неудачная выкатка — не катастрофа. Откат и накат исправления — это заранее спроектированные пути, а не импровизация в три ночи. Зрелый конвейер хранит неизменяемые артефакты с явными версиями, проверяет здоровье на выкатке и даёт быстро выбрать безопасный вариант восстановления. Осторожность здесь одна: DORA показывает связь скорости и стабильности на уровне результатов исследования, а не доказывает, что именно ваша конкретная правка конвейера что-то улучшила.

Метрики DORA измеряют, но цель продукта не заменяют. «Увеличим частоту выкаток», не глядя на нестабильность, — это стимул оптимизировать счётчик, и я такое вижу регулярно. Лечится тем, что на дашборде рядом живут все пять текущих метрик и подписана версия их определений.

Подписанные артефакты и SBOM по умолчанию. Конкретные обязательства и сроки зависят от того, какое регулирование к вам применимо, и это единственная часть темы, которую нельзя списать из чужого блога. Механика же одинаковая для всех: подпись и SBOM дают проверяемые данные о происхождении и составе того, что вы кладёте в прод. Актуальные дорожки SLSA разобраны в Supply Chain Security.

Граница практики проходит по размеру и по частоте изменений. Конвейер за десять минут и карантин для нестабильных тестов окупаются там, где в день проходит хотя бы несколько изменений. Для сервиса, который трогают раз в квартал, вся эта машинерия — накладные расходы. Там честнее ручная сборка по чеклисту и один тест на дым. Обратная сторона тоже есть, и она дороже: конвейер, обвешанный проверками до сорока минут, команда начинает обходить — мержит с флагом «пропустить тесты», выкатывает руками, и формально всё зелёное.

Связанные листья

Progressive Delivery — CI/CD как платформа для canary, blue-green и feature flags. Без надёжного конвейера и trunk-based development они не собираются.
Infrastructure as Code — изменения инфраструктуры проходят тем же конвейером: plan показывает, что будет, apply идёт после согласования.
GitOps — Git как источник истины, CI/CD как движок исполнения.
Programming Languages — тесты, линтеры и сборка любого языка живут внутри конвейера.
Test Strategy — пара к этому листу: тесты живут в конвейере, а без стратегии зелёный CI даёт ложную уверенность.
Supply Chain Security — SLSA, Sigstore, SBOM, одноразовые раннеры. Конвейер — главная поверхность атаки на цепочку поставок.
Secrets Management — тот же OIDC; конвейер — один из главных источников утечек.
Workload Identity — федерация OIDC убирает вечные облачные ключи из секретов репозитория: задача получает короткоживущий токен на один запуск.
Service Ownership — конвейером владеет команда сервиса, а не «централизованный DevOps, который настраивает за всех».
Change Governance — проверка готовности к проду реализуется как рубеж в конвейере; деление изменений на типовые и обычные опирается на то, что конвейер может подтвердить.

Открытые вопросы

Supply Chain Security и DORA Metrics уже уехали в отдельные листья, ссылки в «Связанных». Открытым остаётся Build Reproducibility / Hermetic Builds — детерминированные сборки, подход в духе Bazel, залоченные зависимости. Своего опыта здесь у меня мало, поэтому лист пока не написан.