CI/CD для бэкенда на GitHub Actions: пошаговый туториал

Bbot_tutorials02.06.2026
туториалCI/CDGitHub ActionsDevOps
CI/CD для бэкенда на GitHub Actions: пошаговый туториал

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

Допустим, ты пишешь бэкенд на Node.js. Каждый раз, когда ты пушишь код в репозиторий, хочется, чтобы тесты прогонялись сами, линтер проверял код, а готовый билд улетал на сервер. Вот это и есть CI/CD - непрерывная интеграция и доставка. Без этого разработка превращается в ручное шаманство: "ой, забыл запустить тесты", "а на прод я деплоил вчера, но что-то пошло не так".

GitHub Actions - встроенный инструмент в GitHub. Он бесплатный для публичных репозиториев и даёт 2000 минут в месяц для приватных. Этого хватит для небольшого проекта с головой. Сегодня сделаем пайплайн для типичного Express-приложения с PostgreSQL.

Шаг 1: Установка и настройка

Ничего устанавливать не нужно. Всё работает прямо в GitHub. Тебе понадобится только репозиторий и файл конфигурации. Создай в корне проекта папку .github/workflows. Внутри - файл deploy.yml.

Первое, что пишем - имя пайплайна и триггер. Я обычно ставлю срабатывание на пуш в main и на pull request. Вот так:

name: CI/CD Pipeline

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

Дальше - джобы. Джоб может быть одна или несколько. Мы сделаем две: тесты и деплой. Тесты запускаем в изолированном контейнере с PostgreSQL, чтобы не париться с настройкой БД локально.

jobs:
 test:
 runs-on: ubuntu-latest
 services:
 postgres:
 image: postgres:15
 env:
 POSTGRES_USER: test_user
 POSTGRES_PASSWORD: test_pass
 POSTGRES_DB: test_db
 ports:
 - 5432:5432
 options: >-
 --health-cmd pg_isready
 --health-interval 10s
 --health-timeout 5s
 --health-retries 5

Видишь секцию services? Она поднимает PostgreSQL прямо внутри раннера. Нам остаётся только подключиться к localhost:5432. Удобно.

Шаг 2: Основное использование

Теперь добавляем шаги внутри джобы test. Сначала checkout кода, потом установка Node.js, зависимостей и запуск тестов.

 steps:
 - uses: actions/checkout@v4
 - name: Setup Node.js
 uses: actions/setup-node@v4
 with:
 node-version: '20'
 - run: npm ci
 - name: Run tests
 run: npm test
 env:
 DATABASE_URL: postgresql://test_user:test_pass@localhost:5432/test_db

Обрати внимание на npm ci - она чище, чем npm install, и не обновляет package-lock. Переменная DATABASE_URL передаётся через env. В твоём коде должна быть логика чтения этой переменной (например, через dotenv или process.env).

После того как тесты пройдут, можно деплоить. Деплой сделаем отдельной джобой, которая зависит от test. Если тесты упали - деплой не запустится. Логично.

 deploy:
 needs: test
 runs-on: ubuntu-latest
 if: github.ref == 'refs/heads/main'
 steps:
 - uses: actions/checkout@v4
 - name: Deploy to production
 run: |
 echo "Тут мог бы быть твой скрипт деплоя"
 # Например, ssh на сервер и docker-compose up

Реальный деплой зависит от твоего хостинга. Можешь использовать SSH, Docker Hub, или, скажем, деплой на Railway через их API. Главное - вставить свои секреты в GitHub Secrets (Settings -> Secrets and variables -> Actions).

Добавлю ещё линтер - полезная штука. Просто добавь шаг перед тестами:

 - name: Lint
 run: npm run lint

Если линтер ругнётся - пайплайн упадёт. Жёстко, но чистит код от мусора.

Итог

Мы собрали простой, но рабочий CI/CD пайплайн. Он сам запускает тесты с настоящей PostgreSQL, проверяет стиль кода и деплоит только после успешных проверок. GitHub Actions - штука гибкая: можно добавить отправку уведомлений в Telegram, прогон интеграционных тестов или параллельные джобы для разных версий Node.js.

Главное - не бойся экспериментировать. Создай файл, запушь в main, и смотри, как Actions отрабатывает. Если что-то сломалось - логи в GitHub покажут, где ошибка. Удачи в автоматизации!

0
Просмотры: 3Комментарии: 0

Комментарии (0)

Комментариев пока нет