CI/CD с GitHub Actions: автоматизация тестов и деплоя на сервер

В современной разработке написание кода составляет лишь половину всей работы. Проверка кода, его тестирование и развёртывание на сервере не менее важны, однако выполнять всё это вручную утомительно, медленно и чревато ошибками. Именно для решения этой проблемы появилась методология CI/CD, которая позволяет автоматизировать рутинные процессы и сосредоточиться на действительно важных задачах. В этой статье мы подробно разберём, что такое CI/CD, почему он стал необходимым для современных команд, и как реализовать его на практике с помощью GitHub Actions.

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

Аббревиатура CI/CD объединяет два понятия: Continuous Integration (непрерывная интеграция) и Continuous Delivery или Deployment (непрерывная доставка или развёртывание). Непрерывная интеграция означает, что каждый разработчик регулярно, нередко по несколько раз в день, добавляет свои изменения в общий репозиторий, и каждое такое добавление автоматически проходит через сборку и тестирование. Такой подход помогает выявлять конфликты между разными частями кода на самой ранней стадии, пока они ещё не успели превратиться в серьёзную проблему.

Непрерывная доставка, в свою очередь, представляет собой процесс автоматического развёртывания успешно протестированного кода в продакшен-окружение или на сервер. Главное преимущество этого процесса заключается в том, что ошибки обнаруживаются задолго до того, как они дойдут до конечного пользователя, ещё на этапе разработки. Если вы внесёте небольшое изменение, которое случайно сломает какую-то функцию, автоматические тесты немедленно укажут на это, и вы решите проблему за считанные минуты, а не за часы или дни. В результате команда работает быстрее, качество кода растёт, а путь от написания до пользователя значительно сокращается.

Что такое GitHub Actions

GitHub Actions — это инструмент автоматизации, встроенный непосредственно в платформу GitHub. Он позволяет запускать автоматические задачи в ответ на определённые события в вашем репозитории, например на push кода, открытие pull request или по заданному расписанию. Главное достоинство GitHub Actions состоит в том, что он расположен там же, где уже хранится ваш код, поэтому вам не нужно настраивать или интегрировать отдельные сторонние сервисы для построения процессов автоматизации.

Каждый сценарий автоматизации называется workflow и описывается файлом в формате YAML, который располагается в папке .github/workflows вашего репозитория. GitHub автоматически считывает эти файлы и запускает их, когда выполняются заданные условия. Для выполнения кода GitHub предоставляет собственные облачные серверы, так называемые runner — виртуальные машины, поэтому вам не приходится заботиться о собственной инфраструктуре и её обслуживании.

Структура workflow: триггеры, задачи и шаги

Понимание структуры файла workflow является ключом к освоению CI/CD. Каждый workflow состоит из трёх основных уровней: триггеры определяют, когда именно запускается workflow, задачи (jobs) представляют собой группы работ, которые могут выполняться параллельно или последовательно независимо друг от друга, а шаги (steps) — это конкретные команды, выполняемые внутри каждой задачи по порядку. В приведённом ниже примере показана простейшая структура workflow:

name: CI

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

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

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

В этом примере раздел on определяет триггеры, то есть workflow запускается при push в ветку main или при открытии pull request. Задача build под разделом jobs выполняется на сервере Ubuntu и состоит из четырёх шагов: сначала загружается код, затем подготавливается окружение Node.js, после чего устанавливаются зависимости и, наконец, запускаются тесты.

Автоматический деплой на сервер

После того как тесты успешно пройдены, следующим логичным шагом становится развёртывание кода на сервере. Чаще всего это делается путём подключения к серверу через SSH, загрузки нового кода и перезапуска сервиса. В приведённом ниже примере показан workflow для автоматического деплоя на хостинг-сервер sayt.uz после прохождения тестов:

name: Deploy

on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy to server
        uses: appleboy/ssh-action@v1.0.0
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_KEY }}
          script: |
            cd /var/www/myproject
            git pull origin main
            npm install --production
            pm2 restart app

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

Работа с секретами

В примере выше вы наверняка заметили записи вида ${{ secrets.SSH_KEY }}. Это конфиденциальные данные, которые хранятся через систему секретов GitHub. Пароли сервера, SSH-ключи, API-токены или строки подключения к базе данных никогда не следует записывать прямо в код, потому что с точки зрения безопасности это крайне опасно. Вместо этого их сохраняют в настройках репозитория, в разделе Settings, в подразделе Secrets and variables.

Такие секреты хранятся в зашифрованном виде, и обращаться к ним можно только во время выполнения workflow, при этом даже в логах они автоматически скрываются и заменяются звёздочками. Этот подход гарантирует, что ваши конфиденциальные данные не лежат в репозитории в открытом виде и недоступны посторонним людям. Поэтому управление любыми паролями и ключами исключительно через секреты считается наилучшей практикой и обязательным требованием безопасности.

Тестирование в нескольких окружениях с помощью матрицы

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

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [18, 20, 22]
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm install
      - run: npm test

С такой конфигурацией GitHub Actions автоматически создаст три отдельные задачи, каждая из которых будет выполняться на своей версии Node.js. Это даёт вам уверенность в том, что ваш код стабильно работает во всех окружениях, которыми пользуется широкая аудитория, и помогает заранее выявить несовместимости между версиями, пока они не дошли до пользователей.

Реальная польза и заключение

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

GitHub Actions является одним из самых удобных инструментов для начала этого пути, поскольку он расположен в одном месте с вашим кодом и не требует сложной инфраструктуры для настройки. Если вы развёртываете свой проект на хостинге или сервере sayt.uz, вы можете адаптировать приведённый выше workflow деплоя под свои нужды и полностью автоматизировать весь процесс доставки. Однажды настроенный конвейер CI/CD будет служить вам долгие годы и беречь самый ценный ресурс вашей команды — время.