CI/CD для начинающих: полное руководство

Что такое CI/CD и зачем это вообще надо

CI/CD - это не магия и не очередная модная аббревиатура. Это способ жить и работать, когда ты устал от ручного деплоя и ошибок "на проде".

Представь: ты поправил баг, залил код, а на следующий день выяснилось, что сломалось что-то другое. Знакомо? CI/CD как раз про то, чтобы ловить такие проблемы до того, как они долетят до пользователей.

Расшифровка простая:

• CI (Continuous Integration) - непрерывная интеграция. Ты часто сливаешь свой код в общую ветку, и он автоматически проверяется. Собралось? Тесты прошли? Ок.
• CD (Continuous Delivery или Deployment) - непрерывная доставка или развертывание. Проверенный код автоматически уезжает на сервер. Без рук.

Смысл в том, чтобы превратить боль каждого деплоя в рутину. Нажал кнопку - поехало. Или вообще само поехало.

Как выглядит типичный пайплайн

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

Вот упрощенная схема того, что происходит внутри:

1. Ты делаешь git push в репозиторий (GitHub, GitLab, Bitbucket).
2. CI-сервер (например, Jenkins, GitHub Actions, GitLab CI) ловит это событие.
3. Сервер собирает проект. Если это Node.js - запускает npm install и npm run build.
4. Запускаются тесты. Юнит-тесты, интеграционные, линтеры.
5. Если всё зелено - собирается Docker-образ или артефакт.
6. Этот артефакт деплоится на стейджинг или сразу на прод.

Выглядит как магия, но на деле это просто скрипты, которые выполняются друг за другом.

Практический пример: GitHub Actions для простого веб-приложения

Давай возьмем реальный случай. У тебя есть React-приложение. Ты хочешь, чтобы при каждом пуше в main оно собиралось, тестировалось и деплоилось на Vercel или Netlify.

Создай в репозитории файл .github/workflows/deploy.yml:

name: Deploy to Production

on:
 push:
 branches: [ main ]

jobs:
 build-and-deploy:
 runs-on: ubuntu-latest

 steps:
 - name: Checkout code
 uses: actions/checkout@v3

 - name: Setup Node.js
 uses: actions/setup-node@v3
 with:
 node-version: '18'

 - name: Install dependencies
 run: npm ci

 - name: Run linter
 run: npm run lint

 - name: Run tests
 run: npm test

 - name: Build project
 run: npm run build

 - name: Deploy to Vercel
 run: npx vercel --prod --token=${{ secrets.VERCEL_TOKEN }}

Разбираем по шагам:

• on push branches: [main] - триггер. Только когда ты пушишь в main.
• Checkout - скачивает код.
• Setup Node.js - ставит нужную версию ноды.
• npm ci - чистая установка зависимостей (быстрее и надежнее, чем npm install).
• Lint и Test - проверяют качество кода и работоспособность.
• Build - собирает статику.
• Deploy - отправляет всё на продакшен через Vercel CLI.

Секреты (типа токена) хранятся в настройках репозитория GitHub. Никаких паролей в коде.

Подводные камни и советы новичкам

CI/CD штука полезная, но первые грабли ты соберешь обязательно. Вот что реально важно:

• Не делай пайплайн слишком длинным. Если сборка идет 40 минут, разработчики начнут её игнорировать. Оптимально - до 10-15 минут.
• Тесты должны быть стабильными. Нет ничего хуже "flaky tests" - тестов, которые падают то так, то сяк. Они убивают доверие к пайплайну.
• Используй кеширование. Не качай node_modules каждый раз заново. В GitHub Actions есть встроенный кеш, используй его.
• Не деплой на прод без стейджинга. Сначала пусть код уедет на тестовый сервер. Погоняй его там, убедись, что всё ок, а потом кати на прод.
• Пиши пайплайн как код. Храни конфиги в репозитории. Если кто-то сломает CI, ты всегда сможешь откатить изменения.

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

Что делать, если проект уже большой

Если у тебя микросервисы или монолит, который собирается час, CI/CD всё равно нужен. Просто подход меняется:

• Разбей пайплайн на этапы: сборка, тесты, деплой.
• Используй матрицы (matrix builds) для параллельного запуска тестов на разных версиях.
• Для микросервисов - каждый сервис деплоится независимо. Упал один - остальные работают.
• Добавь автоматический откат (rollback). Если после деплоя мониторинг показал рост ошибок - откатись на предыдущую версию автоматически.

Пример матрицы в GitHub Actions для тестирования на Node 16, 18 и 20:

strategy:
 matrix:
 node-version: [16, 18, 20]

steps:
 - uses: actions/setup-node@v3
 with:
 node-version: ${{ matrix.node-version }}

Это запустит три параллельных джобы. Экономит кучу времени.

Итог

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

Начни с малого: добавь линтер и простой билд. Потом докрути тесты. Потом автодеплой на стейджинг. Через месяц ты удивишься, как раньше жил без этого.

Главное - не пытайся внедрить всё и сразу. Построй простой пайплайн, который работает, и постепенно его улучшай. Остальное придет с опытом.