Вы закоммитили код. Нажали push. Через минуту вам приходит уведомление: пайплайн зелёный. Сайт обновился. Вы выдыхаете.

Это магия CI/CD. Но за этой магией стоит чёткая последовательность шагов. Давайте заглянем под капот GitLab и разберём каждый этап от начала до конца.

Что скрывается за аббревиатурой

CI — непрерывная интеграция. Вы вливаете свой код в общую ветку. Система автоматически собирает проект, запускает тесты и проверяет качество. CD — непрерывная доставка. Собранный и протестированный код автоматически уезжает на сервер или в облако.

В GitLab эта связка управляется файлом .gitlab-ci.yml. Один файл определяет всё поведение пайплайна.

Как выглядит стандартный пайплайн

Я беру типовой проект с бэкендом на Python и фронтендом на React. Пайплайн делится на несколько последовательных стадий (stages). Каждая стадия содержит одну или несколько джоб (jobs). Джобы выполняются параллельно внутри стадии.

Стадия 1. Проверка кода (lint)

Первая остановка. Система проверяет синтаксис, соблюдение стиля и потенциальные ошибки. Для Python это flake8 или black. Для JavaScript — eslint. Если линтер падает, пайплайн останавливается. Код просто не проходит дальше.

Стадия 2. Сборка (build)

Здесь создаётся артефакт. Для Python это может быть установка зависимостей через pip и упаковка в архив. Для фронтенда — сборка через npm build. Артефакт сохраняется внутри пайплайна и передаётся на следующие этапы. Например, скомпилированные файлы или папка с билдом.

Стадия 3. Тестирование (test)

Запускаются все автоматические тесты. Модульные, интеграционные, UI. В GitLab это выглядит как отдельная джоба, которая запускает pytest или jest. Если хотя бы один тест падает, пайплайн становится красным. Вы получаете уведомление. Релиз откладывается.

Стадия 4. Сканирование безопасности (security)

Современный пайплайн часто включает проверку уязвимостей. Инструменты вроде safety или dependency-check сканируют зависимости. Ищут известные CVE. Если найдена критическая дыра — пайплайн останавливается.

Стадия 5. Сборка образа (docker build)

Код упаковывается в Docker-образ. Это делается на основании Dockerfile. Образ содержит всё необходимое для запуска приложения: код, зависимости, настройки окружения. Образ тегируется (например, v1.2.3 или latest) и пушится в контейнерный реестр GitLab.

Стадия 6. Развёртывание (deploy)

Финальная стадия. Образ загружается на сервер. В GitLab есть несколько механизмов. Можно использовать Kubernetes, Ansible, или простой SSH-скрипт. Развёртывание может быть на несколько окружений: staging (тестовое) и production (боевое). Обычно в продакшен деплоят вручную через кнопку, а в стейджинг — автоматически при каждом коммите.

Кейс из моей практики

Однажды я добавил новую фичу и запушил в ветку dev. Пайплайн упал на этапе тестов. Причина — невалидный запрос к внешнему API. Я увидел красный статус, открыл логи, нашёл ошибку, поправил и перезапустил. Через пять минут всё зелёное. Без CI/CD этот баг улетел бы в прод к клиенту.

Как работает управление джобами

В .gitlab-ci.yml каждая джоба содержит ключевые поля:

· stage — к какой стадии относится. · script — команды, которые выполняются (например, pip install, pytest). · only или rules — когда запускать (только на main или на любую ветку). · artifacts — какие файлы сохранить после выполнения. · needs — если джоба зависит от другой.

Зеркало. Разрушаем миф

Многие думают, что CI/CD — это только про автоматизацию деплоя. На деле это про качество. Пайплайн становится вашим первым тестировщиком, код-ревьюером и охранником. Он не даёт сломать продакшен. Он заставляет вас думать о каждом шаге, который вы делаете.

Совет, который я даю новичкам

Начните с простого файла с одной джобой, которая запускает линтер. Добавьте тесты. Потом сборку. Потом деплой. Не пытайтесь объять необъятное. Постепенно ваш пайплайн вырастет до полноценного конвейера.

Какая часть CI/CD в вашем проекте чаще всего падает — тесты, сборка или деплой?