CI/CD для маленькой команды: минимум, который окупается

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

Большой конвейер маленькой команде не нужен. Нужен короткий, который запускается на каждое изменение и которому все доверяют.

Что проверять на каждый пуш

Минимальный набор шагов:

установка зависимостей строго по lock-файлу;
линтер и проверка типов;
тесты;
продакшн-сборка.

Последний пункт часто пропускают, а зря: проект, который собирается в режиме разработки, может не собраться в боевом. Весь прогон стоит держать в пределах десяти минут. Если он дольше, люди начинают вливать изменения, не дожидаясь результата, и проверки превращаются в формальность.

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

Какие тесты писать первыми

Покрытие в процентах на этом этапе мало что говорит. Важнее, чтобы тесты закрывали места, поломка которых стоит денег или доверия:

регистрация и вход;
оплата и начисление того, за что заплатили;
проверка доступа: пользователь не видит чужие данные;
миграции применяются на чистую базу без ошибок.

Это несколько десятков тестов, а не несколько сотен. Их можно написать за пару дней, и они ловят большую часть того, что ломается при правках, особенно при правках, сделанных с ИИ, который охотно меняет соседний код.

Превью для каждой ветки

Превью — отдельная копия приложения для пул-реквеста со своим адресом. Её можно открыть с телефона, показать дизайнеру или заказчику и проверить руками до слияния. Многие хостинги делают это из коробки.

Важно, к чему превью подключено. Своя база с тестовыми данными или общая стейджинговая — нормально. Боевая база и боевые ключи платёжной системы — нет: превью открывают люди, которые не ждут, что их клики спишут настоящие деньги.

Продакшн — по кнопке

Автоматический деплой ветки main на стейджинг удобен. Автоматический деплой в продакшн для маленькой команды — спорный выбор. Ручное подтверждение стоит пять секунд и даёт момент подумать: сейчас пятница вечером, а в релизе миграция.

Два правила, которые избавляют от странных ошибок:

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

Откат

Откат должен быть одной командой или одной кнопкой: вернуть предыдущий артефакт. Если для отката нужно вспоминать, что делали в прошлый раз, его не сделают вовремя. Учти, что откатить код легко, а откатить базу — нет, поэтому миграции стоит писать так, чтобы старая версия кода продолжала с ними работать.

Секреты в конвейере

Ключи хранятся в настройках CI, а не в репозитории. Ключи от продакшна доступны только шагу, который выкатывает в продакшн, а не каждому прогону тестов на каждой ветке. И раз в несколько месяцев стоит проверить, у кого вообще есть к ним доступ.

Если хочется получить такой конвейер за несколько дней, а не собирать его по вечерам, SUBXCAT может настроить его под твой проект.