CI/CD: урок по Инструменты к собеседованию

CI (continuous integration): каждый пуш и каждый pull request автоматически собирается и проверяется: типы, линтер, тесты, сборка. Цель: ошибка видна через минуты, а не в день релиза, и в основную ветку попадает только проверенный код.

CD бывает двух видов:

continuous delivery: каждая зелёная сборка готова к выкатке, но на прод её выкатывают кнопкой;
continuous deployment: каждая зелёная сборка в main выкатывается на прод сама, без человека.

Пайплайн

Типичная цепочка: установка зависимостей, линтер и типы, unit-тесты, сборка, e2e на собранном приложении, публикация артефакта (образ, бандл), деплой на стенд, деплой на прод. Быстрые проверки ставят раньше: если упал линтер, нет смысла ждать 10 минут e2e.

GitHub Actions на примере

# .github/workflows/ci.yml
name: CI
on:
  pull_request:
  push:
    branches: [main]
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
  deploy:
    needs: check
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./deploy.sh

Словарь:

workflow: файл в .github/workflows, запускается по событию (on).
job: набор шагов на одной машине (runner). Джобы идут параллельно, порядок задаётся needs.
step: команда (run) или готовое действие (uses).
runner: машина, где выполняется джоба: облачная от GitHub или своя (self-hosted).
matrix: запуск одной джобы с разными параметрами, например на Node 20 и 22.

Кеш и артефакты

Кеш ускоряет повторные запуски: npm-кеш, кеш сборщика. Ключ обычно включает хеш lock-файла: поменялись зависимости, кеш новый.
Артефакт это результат джобы, который нужно передать дальше или скачать: собранный бандл, отчёт тестов, скриншоты упавших e2e.

В CI ставят зависимости через npm ci: он берёт версии строго из lock-файла и падает, если lock не совпадает с package.json. Так сборка воспроизводима.

Секреты

Ключи и пароли хранят в секретах репозитория или окружения (${{ secrets.DEPLOY_KEY }}), а не в коде. GitHub маскирует их в логах. Для pull request из форков секреты не передаются: иначе любой мог бы прислать PR, который печатает ключи.

Сторонние actions это чужой код с доступом к твоему токену. Надёжнее фиксировать их на конкретный SHA коммита, а не на плавающий тег.

Стратегии выкатки

Rolling: инстансы обновляются по очереди. Есть момент, когда работают обе версии.
Blue-green: рядом с рабочим окружением (blue) поднимается новое (green), проверяется, и трафик переключается целиком. Откат: переключить обратно.
Canary: новую версию получает малая доля трафика (например, 5%), по метрикам решают, катить ли дальше.
Feature flags: код выкачен, но фича включается флагом. Деплой отделён от релиза.

Обе версии одновременно работают при rolling и canary, поэтому миграции базы делают обратно совместимыми: сначала добавить колонку, потом начать писать, и только позже удалить старое.

Частые ошибки

npm install в CI вместо npm ci.
Секреты в коде или в echo в логах.
Долгий пайплайн без кеша и без параллельных джоб.
Деплой без плана отката.
Миграция, которая ломает старую версию приложения во время выкатки.

Что спросят на собесе

Чем continuous delivery отличается от continuous deployment.
Из каких шагов ты бы собрал пайплайн для фронтенда или бэкенда.
Чем кеш отличается от артефакта.
Какие бывают стратегии деплоя и как откатиться.
Как хранить секреты в CI.

CI/CD без магии