Что такое CI/CD и зачем это нужно

CI (Continuous Integration) — автоматический запуск тестов при каждом коммите. CD (Continuous Delivery/Deployment) — автоматическая доставка кода на сервер. Вместе они устраняют ручные этапы между написанием кода и его появлением в продакшене.

Почему это важно: Без CI/CD разработчик вручную запускает тесты (и часто забывает), собирает билд и деплоит через SSH. Это медленно, подвержено ошибкам и не масштабируется. CI/CD делает каждый merge предсказуемым и безопасным.

Главная идея

CI/CD — конвейер: коммит → автоматические проверки (тесты, линтер, сборка) → доставка в окружение. Если любой шаг провалился — пайплайн останавливается, и разработчик получает уведомление.

Как это выглядит на практике

Разработчик пушит ветку feature/add-search в GitHub
CI автоматически запускается: устанавливает зависимости, запускает линтер
Затем запускаются тесты (unit + integration)
Если всё зелёное — PR помечается как ready to merge
После merge в main — CD автоматически деплоит на staging
QA проверяет staging, нажимает Approve
CD деплоит на production и отправляет уведомление в Slack

Примеры кода

Минимальный GitHub Actions workflow

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

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

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

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3'
          bundler-cache: true  # кэширует gem'ы

      - name: Run tests
        run: bundle exec rspec

      - name: Run linter
        run: bundle exec rubocop

CI для Node.js проекта

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

on: [push, pull_request]

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

      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - run: npm ci          # чистая установка из lock-файла
      - run: npm run lint     # ESLint
      - run: npm run typecheck # TypeScript
      - run: npm test         # Jest/Vitest

Что происходит под капотом

CI сервер (GitHub Actions, GitLab CI, Jenkins) слушает события из git-репозитория
Каждый запуск создаёт изолированное окружение (Docker-контейнер или VM)
Шаги выполняются последовательно: если один упал — остальные не запускаются
Кэширование зависимостей (bundler-cache, npm cache) ускоряет пайплайн в 2–5 раз
Статус проверки (зелёный/красный) привязывается к коммиту и виден в PR

Типичные ошибки и заблуждения

«CI/CD — это только для больших команд» — даже соло-разработчик выигрывает от автоматических тестов на каждый коммит
«CD = деплой на прод при каждом коммите» — Continuous Delivery = код всегда готов к деплою, Deployment = деплоится автоматически
«CI заменяет локальные тесты» — CI ловит то, что пропустили локально, но не должен быть единственным местом тестирования

Ключевые выводы

CI = автоматические проверки (тесты, линтер, типы) при каждом коммите/PR
CD = автоматическая доставка проверенного кода на staging/production
Зелёный пайплайн — необходимое условие для merge, красный — блокирует

Термины урока

{:term=>"Pipeline", :definition=>"Последовательность автоматических шагов: от коммита до деплоя"}

{:term=>"Job", :definition=>"Единица работы в пайплайне: например, «запуск тестов» или «сборка Docker-образа»"}

{:term=>"Artifact", :definition=>"Файл, создаваемый пайплайном: билд, Docker-образ, отчёт о тестах"}

Связь с работой backend-разработчика

CI/CD — не luxury, а необходимость. Даже минимальный пайплайн (lint + test на каждый PR) предотвращает регрессии и даёт уверенность при merge. Начните с 10-строчного workflow и расширяйте по мере роста проекта.

Мини-разбор реальной ситуации

Команда из 5 разработчиков деплоила вручную: SSH на сервер, git pull, перезапуск. В пятницу один разработчик забыл запустить тесты и задеплоил баг. Внедрение GitHub Actions CI (тесты обязательны для merge) + CD (автодеплой через Kamal) полностью устранило подобные инциденты.

Что запомнить

CI = автотесты на каждый push/PR — ловит баги до merge
CD = автодеплой проверенного кода — устраняет человеческий фактор
Начните с минимального workflow: checkout → install → test → lint

Итог

CI/CD превращает хаотичный процесс «написал → задеплоил → надеюсь, работает» в предсказуемый конвейер с гарантиями качества. Это одна из самых высокоотдачных инвестиций в инфраструктуру проекта.