GitHub Actions: свой первый CI за вечер
GitHub Actions за вечер: как настроить первый CI-пайплайн, автоматизировать тесты и сборку. Понятный разбор синтаксиса workflow с готовым конфигом для новичка.
Коротко. CI/CD автоматически проверяет и доставляет код. В GitHub Actions пайплайн — это YAML-файл в .github/workflows/, который запускается на события (push, pull request). За вечер реально настроить прогон тестов и линтера на каждый коммит — это уже сильный пункт в портфолио DevOps.
Что такое CI/CD и Actions
CI (Continuous Integration) — на каждый коммит автоматически собирать проект и гонять тесты, чтобы ломающие изменения ловились сразу. CD — автоматически доставлять рабочую версию на сервер. GitHub Actions — встроенный в GitHub инструмент, которому не нужен отдельный сервер.
Как устроен workflow
- workflow — весь сценарий (YAML-файл).
- on — событие-триггер (push, pull_request).
- job — задача, выполняется на раннере (виртуалке).
- step — шаг внутри job (команда или готовый action).
Первый пайплайн
Пример для Node.js-проекта с package-lock.json и командами lint и test в package.json. Они должны проходить локально под Node.js 24. Создайте файл .github/workflows/ci.yml:
name: CI
permissions:
contents: read
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
with:
node-version: 24
- run: npm ci
- run: npm run lint
- run: npm test
Готово: теперь каждый коммит проверяется автоматически, а в PR видно, прошли ли тесты.
Когда подключать деплой
Проверки в CI ещё не означают, что приложение можно автоматически выкладывать на сервер. Сначала пройдите развёртывание на VPS вручную и сохраните рабочие команды обновления, проверки и возврата предыдущей версии.
Потом добавляйте отдельный job с зависимостью needs: test и условием запуска только на push в main. Передайте ему точную версию кода или образа. Для одного окружения ограничьте одновременные релизы через concurrency. Секреты храните в Settings → Secrets, а не в коде. После запуска проверяйте ответ сервиса, а не только успешное завершение SSH-команды.
Советы и ошибки
- ✅ Кэшируйте зависимости (actions/cache) — пайплайн быстрее.
- ✅ Разделяйте jobs: линт, тесты, сборка, деплой.
- ❌ Не кладите секреты в YAML открытым текстом.
- ❌ Не деплойте с любой ветки — ограничивайте условием if.
Как превратить это в пункт портфолио
CI — один из самых окупаемых пунктов в портфолио джуна DevOps, потому что показывает инженерную культуру, а не только «умею писать код». Минимальный сильный вариант: возьмите любой свой проект, добавьте линт и тесты, настройте workflow на push и повесьте бейдж статуса CI в README. Следующий шаг — автодеплой на VPS по push в main. Такой репозиторий на собеседовании говорит за вас лучше строчки в резюме.
Минимальный полезный CI
На каждый PR: checkout → install → lint/test → (опционально) build. Секреты только в secrets, не в логах. Кэш зависимостей — когда пайплайн уже зелёный. Не усложняйте matrix и 15 job, пока один job не стабилен.
- запуск на pull_request + main;
- fail fast на тестах;
- артефакт/отчёт при падении;
- отдельный workflow на release/deploy — когда появится деплой.
CI — часть DevOps-истории в резюме. Рядом: Docker, старт DevOps.
Секреты и supply chain — минимум
Не выводите секреты в логи. В примере GITHUB_TOKEN получает только contents: read. Для рабочего проекта фиксируйте actions по проверенному SHA коммита и обновляйте их осознанно. Пример рассчитан на GitHub-hosted runner. Если используете свой runner, проверьте его совместимость с выбранными версиями actions. Подробнее — рекомендации GitHub.
Следующий шаг в DevOps
Примените идеи из «GitHub Actions: свой первый CI за вечер» к своему учебному проекту или к одной вакансии на этой неделе. Поднимите один сервис в Docker, прогоните простой CI, задеплойте на VPS или в песочницу. База: Docker, VPS. Полный маршрут — DevOps старт, обзор роли — DevOps на уровне джуна.
Убедитесь, что CI ловит поломку
Создайте отдельную ветку и намеренно сломайте один тест. Откройте PR и убедитесь, что проверка стала красной. Исправьте код и получите зелёный результат. Сохраните ссылку на оба запуска: она показывает, что CI действительно проверяет проект, а не просто выполняет команды.
По теме: VPS, Docker, старт DevOps, профессии.
Частые вопросы
GitHub Actions бесплатны?
Для публичных репозиториев — да; для приватных есть бесплатный лимит минут. Для учебных проектов этого хватает.
Actions или GitLab CI?
Принципы одинаковые (YAML, jobs, steps). Освоив одно, легко перейти на другое. Берите то, где лежит ваш код.
Что показать в портфолио?
Репозиторий с рабочим CI: линт + тесты на каждый коммит и бейдж статуса в README.
Материал «GitHub Actions: свой первый CI за вечер» имеет смысл только вместе с практикой: один артефакт в git на этой неделе важнее десяти вкладок с теорией. Если застряли на выборе роли — начните с профессий и одной вакансии-ориентира.