Что такое CI/CD: непрерывная интеграция и доставка

Pipeline от коммита до продакшена: GitHub Actions, GitLab CI, Jenkins. Разбираем YAML-конфиги, стратегии деплоя и типичные ошибки новичков.

Алексей Михайлишин

, отредактировано

Каждый разработчик знает это ощущение: код на локальной машине работает идеально, но стоит выкатить его на сервер — что-то ломается. Или команда из пяти человек неделями не может смержить ветки, потому что конфликты накопились до неуправляемого состояния. Именно для решения этих проблем и появилась практика CI/CD — один из главных столпов современного DevOps.

CI/CD (Continuous Integration / Continuous Delivery) — это набор практик и инструментов, которые автоматизируют сборку, тестирование и доставку программного обеспечения. CI — непрерывная интеграция — обеспечивает автоматическую проверку каждого изменения кода. CD — непрерывная доставка или развёртывание — автоматизирует передачу протестированного кода в production-среду или на стейджинг. Вместе они образуют конвейер (пайплайн), который сокращает время от написания кода до его появления у пользователей с нескольких недель до нескольких минут.

Key Takeaways

- CI (Continuous Integration) — автоматическая сборка и тестирование при каждом коммите в репозиторий - CD бывает двух видов: Continuous Delivery (код готов к деплою вручную) и Continuous Deployment (деплой полностью автоматический) - Пайплайн состоит из этапов: build → test → deploy - По данным DORA Report, команды элитного уровня деплоятся в 208 раз чаще и восстанавливаются после сбоев в 2604 раза быстрее по сравнению с командами низкого уровня - Популярные инструменты: GitHub Actions, GitLab CI/CD, Jenkins, CircleCI, TeamCity - Внедрение CI/CD можно начать за один день — даже для небольшого проекта

Что такое CI — Continuous Integration

Continuous Integration (непрерывная интеграция) — это практика, при которой разработчики регулярно (обычно несколько раз в день) сливают изменения в общую ветку репозитория. Каждое такое слияние автоматически запускает сборку проекта и прогон тестов. Если что-то сломалось — система немедленно уведомляет разработчика.

До появления CI команды работали по модели «интегрируй редко, страдай долго»: каждый разработчик неделями писал код в своей ветке, а потом несколько дней разгребал конфликты при слиянии. Мартин Фаулер, один из авторов концепции, описал это явление как «integration hell» — ад интеграции.

Как работает непрерывная интеграция

Разработчик пишет код и делает коммит в репозиторий (Git)
CI-сервер замечает изменение через webhook или периодический polling
Запускается пайплайн: скачивается код, устанавливаются зависимости, проект компилируется
Прогоняются автоматические тесты — юнит-тесты, интеграционные, линтер
Результат сообщается разработчику: зелёный (всё хорошо) или красный (есть ошибки)

Зачем нужна CI

Ошибки обнаруживаются сразу после коммита, а не через неделю — исправить их несравнимо проще
Исчезает «страх интеграции»: разработчики делают маленькие коммиты и сливают ветки часто
Актуальная сборка всегда доступна для тестирования QA-командой
Код-ревью становится осмысленным: рецензент видит, что тесты прошли
По данным Puppet State of DevOps Report, команды с CI тратят значительно меньше времени на исправление багов

Основное правило CI: если сборка сломана — её починка становится приоритетом номер один для всей команды. Нельзя добавлять новый код в сломанную ветку.

Что такое CD — Continuous Delivery и Continuous Deployment

Аббревиатура CD скрывает два разных понятия, которые часто путают. Разберём каждое из них.

Continuous Delivery — непрерывная доставка

Continuous Delivery (непрерывная доставка) — это практика, при которой код всегда находится в состоянии, готовом к развёртыванию в production. После прохождения всех автоматических проверок релиз выполняется вручную — нажатием кнопки или командой. Это даёт команде контроль над тем, когда именно изменения попадают к пользователям.

Continuous Deployment — непрерывное развёртывание

Continuous Deployment (непрерывное развёртывание) — следующий уровень автоматизации: каждый коммит, прошедший все тесты, автоматически попадает в production без какого-либо ручного вмешательства. Именно так работают крупные технологические компании: Amazon в 2011 году делал деплой в production в среднем каждые 11,6 секунды, а сегодня масштаб ещё выше. Netflix выкатывает изменения тысячи раз в день.

Разница между Delivery и Deployment — это один шаг: ручной или автоматический триггер финального деплоя. Оба подхода требуют зрелой CI-практики и надёжных тестов. Continuous Deployment подходит для продуктов с хорошим покрытием тестами и возможностью быстрого отката. Continuous Delivery — для продуктов, где релиз требует согласования или происходит по расписанию.

Continuous Delivery: CI прошла → код готов → команда деплоит вручную → production
Continuous Deployment: CI прошла → код автоматически деплоится → production

Как устроен CI/CD пайплайн

Пайплайн (pipeline) — это последовательность автоматизированных шагов, которые код проходит от коммита до production. Каждый шаг называется стейджем (stage) или джобой (job). Если любой шаг завершается с ошибкой, пайплайн останавливается и разработчик получает уведомление.

Типичные этапы пайплайна

Source — триггер: push в репозиторий или открытие Pull Request
Build — сборка проекта: компиляция, установка зависимостей, создание артефакта (JAR, Docker-образ, бинарник)
Test — автоматические тесты: юнит-тесты, интеграционные тесты, линтер, проверка покрытия
Security — статический анализ на уязвимости (SAST), проверка зависимостей (SCA)
Staging — деплой на тестовое окружение, smoke-тесты, end-to-end тесты
Deploy — деплой в production (автоматический при Continuous Deployment, ручной при Continuous Delivery)

Пример: GitLab CI/CD (.gitlab-ci.yml)

Конфигурация пайплайна хранится прямо в репозитории в виде YAML-файла. Вот минимальный рабочий пример для Node.js-проекта:

			# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

variables:
  NODE_VERSION: "20"

build:
  stage: build
  image: node:20
  script:
    - npm ci
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 hour

test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm run lint
    - npm test -- --coverage
  coverage: '/Lines\s*:\s*(\d+\.?\d*)%/'

deploy_staging:
  stage: deploy
  script:
    - echo "Деплой на staging..."
    - ./scripts/deploy.sh staging
  environment:
    name: staging
    url: https://staging.example.com
  only:
    - main

deploy_production:
  stage: deploy
  script:
    - ./scripts/deploy.sh production
  environment:
    name: production
    url: https://example.com
  only:
    - main
  when: manual  # Continuous Delivery: ручной триггер

Пример: GitHub Actions (.github/workflows/ci.yml)

			# .github/workflows/ci.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linter
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

  deploy:
    needs: build-and-test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to production
        run: ./scripts/deploy.sh
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}

Как внедрить CI/CD в проект: пошаговая инструкция

Внедрение CI/CD не требует немедленной перестройки всего процесса. Начните с малого — добавьте автоматический запуск тестов при каждом коммите. Этот первый шаг уже даст ощутимую пользу.

Шаг 1. Настройте репозиторий и напишите тесты

CI без тестов бессмысленна. Если тестов нет — начните с покрытия хотя бы критических сценариев. Убедитесь, что проект можно собрать из чистой среды одной командой (например, npm install && npm test). Если это не работает у вас локально — не заработает и в CI.

Шаг 2. Выберите инструмент CI/CD

Для начинающих рекомендуем GitHub Actions — если код уже на GitHub, дополнительная регистрация не нужна. Создайте файл .github/workflows/ci.yml прямо в репозитории. Для GitLab-проектов — GitLab CI/CD с файлом .gitlab-ci.yml. Оба инструмента имеют обширную документацию и готовые шаблоны.

Шаг 3. Создайте минимальный пайплайн

			# Минимальный GitHub Actions для Python-проекта
# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      - run: pip install -r requirements.txt
      - run: pytest

Закоммитьте этот файл. Перейдите во вкладку «Actions» на GitHub — вы увидите первый запущенный пайплайн. Зелёная галочка означает, что тесты прошли.

Шаг 4. Добавьте линтер и code quality

Добавьте в пайплайн запуск линтера (ESLint для JS, pylint/flake8 для Python, golangci-lint для Go). Это поможет поддерживать единый стиль кода без ручных проверок. Настройте автоматическую проверку на pull request — тогда рецензент сразу видит, что стиль соблюдён.

Шаг 5. Настройте деплой на стейджинг

Когда CI работает стабильно, добавьте автоматический деплой на staging-окружение при каждом успешном прогоне в ветке main. Это реализует Continuous Delivery. Для деплоя используйте секреты (Secrets) в настройках репозитория — никогда не храните пароли и ключи прямо в YAML-файле. После того как команда убедится в надёжности процесса, можно переходить к Continuous Deployment.

Чек-лист готовности CI/CD

Проект собирается из чистой среды одной командой
Есть автоматические тесты с покрытием >60%
Пайплайн запускается при каждом push и pull request
Сломанная сборка блокирует слияние ветки
Секреты хранятся в переменных окружения CI, не в коде
Команда получает уведомления о статусе сборки
Есть процедура отката деплоя при проблемах

Связанные технологии

CI/CD неразрывно связан с другими DevOps-практиками. Git — основа любого CI/CD-процесса: без системы контроля версий невозможно отслеживать изменения и запускать пайплайны. Docker и контейнеры обеспечивают воспроизводимую среду сборки и деплоя: то, что работает в CI, гарантированно работает в production. Микросервисная архитектура хорошо сочетается с CI/CD: каждый сервис имеет собственный пайплайн и деплоится независимо.

Частые вопросы

В чём разница между CI и CD?

CI (Continuous Integration) — это автоматическая сборка и тестирование кода при каждом коммите. CD (Continuous Delivery / Deployment) — автоматическая доставка проверенного кода в production-среду. CI отвечает на вопрос «работает ли мой код?», CD — на вопрос «как быстро и надёжно доставить его пользователям?». Без CI нет смысла в CD: нельзя автоматически деплоить код, который не проверяется.

Нужен ли CI/CD маленькому проекту?

Да, даже для проекта в одного разработчика. Минимальный пайплайн с запуском тестов занимает 15 минут на настройку и сразу начинает экономить время: CI поймает опечатки и регрессии, которые вы бы заметили уже на production. Кроме того, наличие CI/CD — это сигнал качества при поиске работы или привлечении контрибьюторов.

Сколько времени занимает настройка CI/CD с нуля?

Базовый пайплайн (build + test) настраивается за 30–60 минут при наличии работающих тестов. Добавление деплоя занимает ещё 1–2 часа в зависимости от сложности инфраструктуры. Полноценная CI/CD-система с несколькими окружениями, матричными сборками и автоматическим откатом — задача на несколько дней для опытной команды.

Что такое «сломанная сборка» и что с ней делать?

Сломанная сборка (broken build) — это когда пайплайн завершился с ошибкой: код не компилируется, тесты упали или линтер нашёл критические ошибки. Золотое правило CI: сломанная сборка — это пожар, который нужно тушить немедленно. Виновник должен либо быстро исправить проблему, либо откатить свой коммит, чтобы не блокировать остальную команду.

GitHub Actions или GitLab CI — что выбрать?

Если ваш код хранится на GitHub — GitHub Actions. Если на GitLab — GitLab CI/CD. Оба инструмента примерно равны по возможностям, разница в деталях и экосистеме. GitHub Actions имеет более богатый маркетплейс готовых интеграций. GitLab CI лучше подходит для компаний с self-hosted инфраструктурой и более строгими требованиями к безопасности.

Выводы

CI/CD — это не магия и не прерогатива крупных компаний. Это инженерная дисциплина, доступная любой команде и любому разработчику-одиночке. Автоматическая проверка кода при каждом коммите, быстрый фидбек об ошибках, воспроизводимые сборки — всё это снижает риски, ускоряет разработку и делает деплой рутинным событием, а не стрессом.

По данным многолетних исследований DORA (DevOps Research and Assessment), команды с высоким уровнем CI/CD-зрелости деплоятся в 208 раз чаще, имеют в 7 раз меньше процент неудачных изменений и восстанавливаются после инцидентов в 2604 раза быстрее по сравнению с командами с низким уровнем автоматизации.

С чего начать прямо сейчас

Откройте любой свой GitHub-репозиторий и создайте файл .github/workflows/ci.yml
Добавьте в него установку зависимостей и запуск тестов (см. пример выше)
Сделайте коммит — перейдите во вкладку Actions и посмотрите на первый пайплайн
Настройте уведомления: GitHub умеет слать письма при красной сборке
Постепенно добавляйте шаги: линтер, деплой на staging, security-проверки

Если вы ещё не работали с системами контроля версий — начните с изучения Git и GitHub: без них CI/CD невозможен. А если уже готовы к контейнеризации — изучите Docker: связка Docker + CI/CD является стандартом современной разработки.

Если хотите увидеть, как CI/CD встраивается в общую картину DevOps, посмотрите план обучения DevOps-инженера. Там показано, какие темы нужно закрыть до пайплайнов и что логично учить после них.

В этой статье

Key Takeaways
Что такое CI — Continuous Integration
Что такое CD — Continuous Delivery и Continuous Deployment
Как устроен CI/CD пайплайн
Популярные инструменты CI/CD
Как внедрить CI/CD в проект: пошаговая инструкция
Связанные технологии
Частые вопросы
Выводы