Главная/CI/CD/Обзор

Раздел 16. CI/CD

Раздел собирает весь курс в один автоматический процесс: от коммита до опубликованного и проверенного образа. Это не обзор возможностей CI-систем, а построение конкретного работающего pipeline с разбором каждого решения.

Pipeline выполняет двенадцать шагов: проверка форматирования, линтинг, проверка типов, unit-тесты, сборка образа с кэшем, integration-тесты на собранном образе, сканирование, генерация SBOM, тегирование по commit SHA, публикация в registry — и всё это без раскрытия секретов в логах.

Основной пример — GitHub Actions, полностью рабочий. Эквивалентная логика для GitLab CI даётся кратко, с акцентом на различия подходов.

Цели обучения

После раздела учащийся сможет:

спроектировать pipeline: определить этапы, их порядок и условия выполнения;
объяснить, какие проверки должны блокировать сборку, а какие — только предупреждать;
написать рабочий workflow для GitHub Actions, собирающий и публикующий образ;
настроить build cache в CI и объяснить, почему без него сборка занимает минуты;
запускать integration tests на собранном образе, а не на пересобранном коде;
встроить сканирование уязвимостей и осмысленно реагировать на результаты;
генерировать SBOM и provenance;
организовать tagging по commit SHA и ветке;
передавать credentials безопасно и не допускать их появления в логах;
воспроизвести ту же логику в GitLab CI.

Предварительные знания

Раздел 14. Registry — публикация и tagging;
Раздел 15. Testing — тесты, которые pipeline будет запускать;
Раздел 11. Production — требования к образу;
Раздел 12. Security — обращение с секретами;
базовое знакомство с Git и понятием pull request.

Материалы

Проектирование pipeline
Этапы и их порядок. Быстрые проверки перед медленными. Что запускать на каждый коммит, что на pull request, что только на main. Блокирующие и информационные шаги. Параллельные задачи и зависимости между ними. Идемпотентность и повторный запуск. Целевое время прохождения.
GitHub Actions
Полный рабочий workflow с разбором каждого шага: checkout, кэширование зависимостей, ruff, mypy, pytest, сборка через docker/build-push-action, integration tests, сканирование, публикация. Secrets и GITHUB_TOKEN. Матрица версий. Условия выполнения по ветке и событию.
Build cache в CI
Почему сборка в CI не использует локальный кэш. Типы кэша: registry, GitHub Actions cache, inline. Настройка cache-from и cache-to. Многоступенчатый кэш для multi-stage builds. Измерение эффекта. Типичная ошибка: кэш, который не переиспользуется между ветками.
Сканирование и SBOM
Встраивание сканера в pipeline. Политика реагирования: какие уязвимости блокируют сборку, а какие фиксируются как задача. Ложные срабатывания и исключения. Генерация SBOM при сборке, форматы, хранение. Attestations и provenance. Что делать с найденной уязвимостью в базовом образе.
GitLab CI
Эквивалентный .gitlab-ci.yml. Различия моделей: stages и jobs, services, Docker-in-Docker против сокета runner, встроенный registry, кэш и артефакты. Переменные и protected secrets. Когда логика переносится один в один, а когда требует изменения подхода.
Практические задания
Лабораторные задания раздела с проверкой результата.

Рабочие примеры

Пример	Каталог	Урок
Полный pipeline	`resources/examples/ci-pipeline/`	02, 03, 04, 05

Практические задания

№	Задание	Тип
1	Написать workflow, запускающий линтер и тесты на каждый push	обяз.
2	Добавить сборку образа и публикацию в registry по тегу с commit SHA	обяз.
3	Настроить build cache и измерить время сборки до и после	обяз.
4	Запустить integration tests на собранном образе внутри pipeline	обяз.
5	Убедиться, что секреты не появляются в логах pipeline ни на одном шаге	обяз.
6	Добавить сканирование и настроить условие блокировки по уровню критичности	доп.
7	Сгенерировать SBOM и сохранить его как артефакт сборки	доп.
8	Настроить публикацию только для ветки `main`, оставив сборку для всех веток	доп.
9	Pipeline собирает образ 8 минут при неизменных зависимостях. Найти причину	диаг.
10	Перенести тот же pipeline в GitLab CI и объяснить, что пришлось изменить	★

Полные формулировки — в exercises.md.

Критерии завершения раздела

Раздел пройден, когда учащийся может без подсказок:

Перечислить этапы pipeline в правильном порядке и объяснить, почему именно такой.
Написать работающий workflow, публикующий образ в registry.
Настроить кэш так, чтобы повторная сборка при неизменных зависимостях занимала менее минуты.
Объяснить, почему integration tests должны запускаться на собранном образе.
Гарантировать, что токен registry не попадёт в логи.
Объяснить, какой тег развёртывать в production и почему не latest.

Проверьте себя: Quiz 16 и Checkpoint 4. Затем выполните Проект 4. Production pipeline.

Что дальше

Практическая часть курса завершена. Оставшиеся три раздела углубляют понимание и формируют инженерное суждение: как Docker устроен изнутри, чем он отличается от Kubernetes и где его применять не следует.