CI/CD для WordPress: Автоматический деплой через GitHub Actions

Если вы до сих пор подключаетесь к серверу по FTP, вручную загружаете измененные файлы темы или плагина, а потом боитесь, что перезаписали wp-config.php — пора переходить на современные практики DevOps. CI/CD (Continuous Integration / Continuous Deployment) позволяет автоматически выгружать код на сервер при каждом коммите в Git, исключая человеческий фактор.

В этом руководстве мы настроим автоматический деплой WordPress-темы и кастомных плагинов на продакшн-сервер с помощью GitHub Actions и rsync. Это бесплатно, безопасно и занимает всего 15 минут настройки.

Почему GitHub Actions, а не FTP или плагины?

  • Безопасность: Вы не храните пароли от FTP в открытом виде. Доступ к серверу осуществляется по SSH-ключам.
  • Скорость: rsync передает только измененные файлы, а не весь архив.
  • Исключение ошибок: Вы случайно не удалите папку uploads или файл wp-config.php, если правильно настроите игнорирование.
  • История изменений: Git хранит всю историю. Если деплой сломал сайт, вы можете откатиться к предыдущему коммиту в один клик.

Шаг 1: Подготовка сервера (SSH и rsync)

Для деплоя нам понадобится доступ по SSH и установленный rsync на сервере.

# Подключаемся к серверу
ssh user@your_server_ip

# Проверяем, установлен ли rsync
rsync --version

# Если не установлен (для Ubuntu/Debian)
sudo apt update && sudo apt install rsync -y

Создание пользователя для деплоя (опционально, но рекомендуется)

Не используйте root для деплоя. Создайте отдельного пользователя с правами только на папку сайта:

sudo adduser deployer
sudo usermod -aG www-data deployer
sudo setfacl -R -m g:www-data:rwx /var/www/wordpress
sudo setfacl -dR -m g:www-data:rwx /var/www/wordpress

Шаг 2: Генерация SSH-ключей на GitHub

GitHub Actions будет подключаться к вашему серверу. Для этого нужна пара SSH-ключей.

1. Генерация ключей на локальной машине:

ssh-keygen -t ed25519 -C "github-actions-deploy" -f ~/.ssh/github_deploy

2. Добавление публичного ключа на сервер:

# Копируем публичный ключ на сервер
ssh-copy-id -i ~/.ssh/github_deploy.pub deployer@your_server_ip

# Или вручную добавляем содержимое github_deploy.pub в ~/.ssh/authorized_keys на сервере

3. Добавление приватного ключа в GitHub Secrets:

  • Откройте репозиторий на GitHub → SettingsSecrets and variablesActions.
  • Создайте новый секрет SSH_PRIVATE_KEY и вставьте содержимое файла ~/.ssh/github_deploy (без расширения .pub).
  • Создайте секрет SSH_HOST (IP-адрес или домен вашего сервера).
  • Создайте секрет SSH_USERNAME (например, deployer).

Шаг 3: Настройка .gitignore и .rsyncignore

Критически важный шаг. Мы не должны деплоить системные файлы WordPress, папку uploads и конфигурации.

Файл .gitignore (в корне репозитория):

# Исключаем ядро WordPress и стандартные плагины
/wordpress/
/wp-admin/
/wp-includes/
/wp-content/plugins/
/wp-content/themes/twentytwentyfour/

# Оставляем только нашу кастомную тему и плагины
!wp-content/themes/custom-theme/
!wp-content/plugins/custom-plugin/

# Исключаем конфиги и uploads
wp-config.php
.htaccess
wp-content/uploads/
*.log

Файл .rsyncignore (для rsync):

Создайте файл .rsyncignore в корне репозитория, чтобы rsync не трогал лишнее даже если оно есть в репозитории:

.git/
.gitignore
.rsyncignore
.github/
node_modules/
wp-config.php
wp-content/uploads/

Шаг 4: Создание GitHub Actions Workflow

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

name: Deploy to Production

on:
  push:
    branches:
      - main # Деплой только при пуше в main

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

      - name: Setup SSH
        uses: webfactory/ssh-agent@v0.9.0
        with:
          ssh-private-key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Add server to known_hosts
        run: |
          mkdir -p ~/.ssh
          ssh-keyscan -H ${{ secrets.SSH_HOST }} >> ~/.ssh/known_hosts

      - name: Deploy via rsync
        run: |
          rsync -avz --delete \
            --exclude-from='.rsyncignore' \
            ./ ${{ secrets.SSH_USERNAME }}@${{ secrets.SSH_HOST }}:/var/www/wordpress/
          
      - name: Clear cache (опционально)
        run: |
          ssh ${{ secrets.SSH_USERNAME }}@${{ secrets.SSH_HOST }} 'cd /var/www/wordpress && wp cache flush'

Шаг 5: Разбор YAML-файла

  • on: push: branches: [main] — пайплайн запускается только при пуше в ветку main. Для тестов используйте ветку develop.
  • actions/checkout@v4 — скачивает ваш код в раннер GitHub.
  • webfactory/ssh-agent — безопасный способ добавить SSH-ключ в окружение GitHub Actions.
  • ssh-keyscan — добавляет хост сервера в known_hosts, чтобы SSH не спрашивал подтверждение при первом подключении.
  • rsync -avz —delete — синхронизирует файлы. Флаг --delete удаляет на сервере файлы, которые были удалены в репозитории. Флаг --exclude-from использует наш файл игнорирования.

Шаг 6: Тестирование деплоя

Внесите небольшое изменение в вашу тему (например, добавьте комментарий в style.css), закоммитьте и запушьте в main:

git add .
git commit -m "feat: update header styles"
git push origin main

Перейдите в GitHub → вкладка Actions. Вы увидите запущенный пайплайн Deploy to Production. Если всё настроено верно, через 30-60 секунд вы увидите зеленую галочку, а изменения появятся на сайте.

Шаг 7: Откат изменений (Rollback)

Если деплой сломал сайт, откатиться можно двумя способами:

Способ 1: Через Git (Revert)

git revert HEAD
git push origin main

Способ 2: Через GitHub UI

  • Зайдите в Actions → выберите последний успешный деплой.
  • Нажмите Re-run jobs (если нужно просто перезапустить) или откатите коммит через интерфейс GitHub.

Если изменения уже применены на сервере и сломали его, используйте бэкапы, которые мы настраивали ранее, или откатите файлы вручную через rsync с локальной машины.

Что делать, если проблемы не решаются?

Ошибка «Host key verification failed»

GitHub Actions не может подтвердить подлинность сервера. Убедитесь, что шаг Add server to known_hosts выполняется корректно и IP-адрес в SSH_HOST совпадает с реальным.

Ошибка «Permission denied (publickey)»

Неверный приватный ключ или он не добавлен в authorized_keys на сервере. Проверьте права на файл ~/.ssh/authorized_keys (должны быть 600) и на папку ~/.ssh (должны быть 700).

Файлы не обновляются на сервере

Проверьте пути в команде rsync. Убедитесь, что вы синхронизируете правильную директорию. Также проверьте файл .rsyncignore — возможно, вы случайно исключили нужные файлы.

Деплой слишком долгий

Если вы передаете много мелких файлов (например, node_modules или скомпилированные ассеты), rsync будет работать медленно. Убедитесь, что node_modules и папки кэша исключены. Для очень больших проектов рассмотрите создание архива (tar) и его передачу, но для тем и плагинов WordPress rsync идеален.

Итог

Настройка CI/CD через GitHub Actions превращает рутинный процесс выгрузки файлов в надежный, автоматизированный пайплайн. Вы тратите время на написание кода, а не на копирование файлов по FTP. В сочетании с WP-CLI для очистки кэша и Uptime Kuma для мониторинга, вы получаете полноценный DevOps-стек для WordPress, доступный даже на небольших VPS.