Если вы до сих пор подключаетесь к серверу по 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_deploy2. Добавление публичного ключа на сервер:
# Копируем публичный ключ на сервер
ssh-copy-id -i ~/.ssh/github_deploy.pub deployer@your_server_ip
# Или вручную добавляем содержимое github_deploy.pub в ~/.ssh/authorized_keys на сервере3. Добавление приватного ключа в GitHub Secrets:
- Откройте репозиторий на GitHub → Settings → Secrets and variables → Actions.
- Создайте новый секрет
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.