DEV Community

Андрей Викулов (VProger)
Андрей Викулов (VProger)

Posted on • Originally published at viku-lov.ru on

CI/CD и GitHub Actions: workflow, secrets, тесты и деплой на практике (Node.js, Python, Docker)

#devops #githubactions #github #cicd

CI/CD на практике: GitHub + GitHub Actions простыми словами

Если коротко:

CI/CD — это когда рутинную работу делает машина, а не ты.

Коммиты проверяются автоматически, сборка не забывается, деплой не ломается «вручную в пятницу вечером».

А теперь — спокойно, по шагам и без магии.

Что вообще такое CI и CD

CI — Continuous Integration (непрерывная интеграция)

CI — это процесс, при котором каждое изменение кода автоматически проверяется.

Обычно CI делает следующее:

  • забирает код из репозитория
  • ставит зависимости
  • запускает тесты
  • проверяет линтеры
  • сообщает: «всё ок» или «сломал — чини»

💡 Главная идея CI:

Ошибки нужно ловить сразу, а не через неделю в проде.

CD — Continuous Delivery / Continuous Deployment

CD — это логическое продолжение CI.

  • Continuous Delivery — код готов к деплою всегда, но выкладка по кнопке
  • Continuous Deployment — код автоматически уезжает на сервер после успешных проверок

Проще говоря:

  • CI — «код жив?»
  • CD — «код поехал»

Почему GitHub Actions — это удобно

GitHub — это не только репозиторий.

Внутри него есть GitHub Actions — встроенная система CI/CD.

Плюсы:

  • не нужен отдельный Jenkins / GitLab Runner
  • YAML лежит рядом с кодом
  • бесплатный лимит для публичных репозиториев
  • огромная экосистема готовых action-ов

Минусы тоже есть, но для 90% проектов — это идеальный старт.

Базовая терминология (без заумных слов)

| Термин | Что это значит |

| -------- | -------------------------------- |

| workflow | сценарий CI/CD |

| job | отдельная задача внутри workflow |

| step | конкретный шаг (команда) |

| runner | машина, где всё выполняется |

| action | готовый блок действий |

Где живёт CI/CD в репозитории

GitHub Actions всегда лежат здесь:


.github/

└── workflows/

└── ci.yml
Enter fullscreen mode Exit fullscreen mode

Название файла любое, главное — расширение .yml.

Самый простой CI: проверка кода

Начнём с минимального, но рабочего примера.

Пример: CI для Node.js проекта


name: CI

on:

push:

branches: [main]

pull\_request:

jobs:

build:

runs-on: ubuntu-latest

steps:

- name: Забираем код

uses: actions/checkout@v4

- name: Устанавливаем Node.js

uses: actions/setup-node@v4

with:

node-version: 20

- name: Устанавливаем зависимости

run: npm ci

- name: Запускаем тесты

run: npm test
Enter fullscreen mode Exit fullscreen mode

Разберём этот файл по-человечески

name


name: CI
Enter fullscreen mode Exit fullscreen mode

Название workflow — просто для удобства в интерфейсе GitHub.

on — когда запускать


on:

push:

branches: [main]

pull\_request:
Enter fullscreen mode Exit fullscreen mode

Это означает:

  • при каждом пуше в main
  • при каждом pull request

💡 Совет:

CI обязан запускаться на PR — иначе смысл теряется.

jobs


jobs:

build:
Enter fullscreen mode Exit fullscreen mode

Workflow может состоять из нескольких job-ов.

Здесь job один — build.

runs-on


runs-on: ubuntu-latest
Enter fullscreen mode Exit fullscreen mode

GitHub даёт виртуальную машину с Ubuntu.

Есть ещё windows-latest и macos-latest.

steps

Steps — это пошаговый сценарий:

  1. забрать код
  2. поставить окружение
  3. выполнить команды

actions/checkout


uses: actions/checkout@v4
Enter fullscreen mode Exit fullscreen mode

Без этого шага кода просто не будет.

Это обязательный минимум.

actions/setup-node


uses: actions/setup-node@v4
Enter fullscreen mode Exit fullscreen mode

Ставит Node.js нужной версии.

Аналоги есть для Python, PHP, Java, Go.

npm ci vs npm install

Используем npm ci, потому что:

  • быстрее
  • строго по package-lock.json
  • идеально для CI

CI для Python (пример)


- uses: actions/setup-python@v5

with:

python-version: "3.12"

- run: pip install -r requirements.txt
- run: pytest
Enter fullscreen mode Exit fullscreen mode

Просто. Читаемо. Без шаманства.

Добавляем линтеры

CI без линтеров — это полдела.

Пример:


- name: Lint

run: npm run lint
Enter fullscreen mode Exit fullscreen mode

Или для Python:


- run: ruff check .
Enter fullscreen mode Exit fullscreen mode

Docker в CI/CD

Если проект использует Docker, добавляем сборку образа:


- name: Build Docker image

run: docker build -t myapp:latest .

- name: Run tests in container

run: docker run --rm myapp:latest npm test
Enter fullscreen mode Exit fullscreen mode

💡 Совет: используй Docker Hub или GitHub Container Registry для хранения образов.

CI ≠ CD: добавляем деплой

Теперь самое интересное — автоматическая выкладка.

Пример: деплой по SSH


- name: Deploy

run: |

ssh user@server "cd /var/www/app && git pull && npm run build"
Enter fullscreen mode Exit fullscreen mode

❗ Но так делать нельзя, если:

  • нет ключей
  • нет secrets
  • нет ограничений по веткам

Secrets — как не спалить пароли

GitHub даёт Secrets:

  • Settings → Secrets and variables → Actions
  • Добавляем SSH_PRIVATE_KEY, SERVER_HOST и т.д.

Использование:


env:

SSH\_KEY: ${{ secrets.SSH\_PRIVATE\_KEY }}
Enter fullscreen mode Exit fullscreen mode

💡 Правило:

Никогда не храни пароли в YAML. Никогда.

Деплой только из main


if: github.ref == 'refs/heads/main'
Enter fullscreen mode Exit fullscreen mode

Так ты не уронишь прод случайным пушем из фичи.

Типичная схема CI/CD проекта

  1. PR → CI
  2. CI зелёный → merge
  3. merge в main → CI
  4. CI успешен → CD
  5. CD выкатил код

Всё. Никакой магии.

Частые ошибки новичков

  • ❌ CI запускается только вручную
  • ❌ Нет проверки PR
  • ❌ Всё в одном step
  • ❌ Пароли в YAML
  • ❌ Деплой без условий
  • ❌ Нет логов

Хорошая практика

  • ✔ Разделяй CI и CD
  • ✔ Минимум логики в YAML
  • ✔ Проверки обязательны
  • ✔ Деплой только из main
  • ✔ Secrets — только через GitHub
  • ✔ Логи читаемы

Когда GitHub Actions — не лучший выбор

Честно:

  • очень сложная оркестрация
  • кастомные runner-ы
  • тяжёлые enterprise-процессы

Тогда смотри в сторону GitLab CI или Jenkins.

Но для старта, пет-проектов и малого бизнеса — GitHub Actions более чем достаточно.

Итог

CI/CD — это не «модно», а необходимость.

GitHub Actions позволяет:

  • автоматизировать проверки
  • убрать человеческий фактор
  • ускорить релизы

  • спать спокойнее

  • Если CI нет — ты тестировщик

  • Если CD нет — ты деплойщик

  • Если есть оба — ты инженер 😏

Read more on viku-lov.ru

Top comments (0)