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

CI/CD простыми словами

CI/CD — практика, при которой путь кода от разработчика до пользователей выполняет автоматика, а не человек по памяти. Каждое изменение проходит один и тот же конвейер (пайплайн): сборка, тесты, проверки, развёртывание.

Аббревиатура объединяет три понятия:

• Continuous Integration (CI) — непрерывная интеграция. Разработчики часто вливают изменения в общую ветку, и при каждом изменении автоматически запускаются сборка и тесты. Цель — узнать о поломке через минуты, а не через неделю.
• Continuous Delivery — непрерывная доставка. Каждая версия, прошедшая проверки, готова к выпуску. Выкладка на продакшен — одна кнопка, решение принимает человек.
• Continuous Deployment — непрерывное развёртывание. Шаг дальше: версия, прошедшая все проверки, уходит на продакшен автоматически, без ручного подтверждения.

Чем delivery отличается от deployment

Начинать почти всегда стоит с CI и continuous delivery. Полностью автоматический деплой — следующий шаг, когда команда доверяет своим тестам.

Типичный пайплайн по шагам

1. Триггер. Разработчик отправляет код или открывает pull request.
2. Сборка. Устанавливаются зависимости, проект компилируется, собирается Docker-образ.
3. Статические проверки. Линтеры, форматирование, проверка типов, сканирование зависимостей на известные уязвимости.
4. Тесты. Модульные, затем интеграционные. Если что-то упало — пайплайн останавливается, автор получает уведомление.
5. Артефакт. Готовая сборка сохраняется с уникальной версией, например образ с тегом по хешу коммита.
6. Деплой на staging. Та же сборка выкатывается в тестовое окружение, похожее на продакшен.
7. Приёмочные проверки. Автотесты сценариев или ручная проверка.
8. Деплой на продакшен. По кнопке или автоматически, желательно постепенно.
9. Мониторинг и откат. Если метрики ухудшились — быстрый возврат к предыдущей версии.

Пример минимального пайплайна в GitHub Actions:

name: ci
on:
  pull_request:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npm run lint
      - run: npm test

Похожие пайплайны строятся в GitLab CI, Jenkins и других системах — принцип тот же.

Что это даёт бизнесу

• Быстрее выход фич. Готовая функция попадает к пользователям, как только прошла проверки, а не ждёт «большого релиза».
• Меньше риска. Маленькие частые релизы проще проверить и откатить, чем редкие большие.
• Меньше ручной работы. Никто не копирует файлы на сервер вручную и не забывает шаг из инструкции.
• Предсказуемость. Каждая версия собирается одинаково, и всегда понятно, что сейчас работает на продакшене.
• Независимость от одного человека. Процесс выпуска описан в коде, а не в голове одного разработчика.

Частые ошибки при внедрении

• Пайплайн без тестов. Автоматический деплой непроверенного кода просто быстрее доставляет ошибки.
• Медленный пайплайн. Если проверки идут слишком долго, их начинают обходить. Кэшируйте зависимости, запускайте шаги параллельно.
• Нестабильные тесты. Тесты, которые падают случайно, приучают игнорировать красный статус.
• Секреты в репозитории. Пароли и ключи хранятся в защищённых переменных CI, а не в коде.
• Разные сборки для staging и продакшена. На продакшен должен уходить тот же артефакт, что прошёл проверку.
• Нет плана отката. Откат должен быть такой же простой операцией, как деплой.

Справка по синтаксису — в документации GitHub Actions.