GitHub Actions для WordPress плагина: полное руководство по CI/CD

Введение: зачем CI/CD в разработке плагинов

Современная разработка WordPress плагинов требует быстрого и надёжного цикла поставки. CI/CD (Continuous Integration / Continuous Delivery) позволяет автоматизировать проверку кода, запуск unit‑тестов и деплой на staging‑сервер без ручного вмешательства. GitHub Actions – встроенный в GitHub сервис, который поддерживает Docker, Composer и PHP‑инструменты, делая процесс настройки удобным и масштабируемым.

Шаг 1. Подготовка репозитория и структуры плагина

Перед тем как писать workflow, убедитесь, что ваш плагин имеет следующую структуру:

my-plugin/ ├── src/ # Исходный PHP‑код ├── tests/ # PHPUnit‑тесты ├── my-plugin.php # Главный файл плагина ├── composer.json # Зависимости (если есть) └──.github/ └── workflows/ └── ci.yml # Файл GitHub Actions 

Если в проекте уже используется Composer, добавьте автозагрузку в composer.json и запустите composer install локально.

Шаг 2. Создание workflow‑файла CI.yml

Файл .github/workflows/ci.yml описывает последовательность действий, которые будет выполнять GitHub Actions при каждом push или pull‑request.

name: CI/CD for WordPress Plugin on: push: branches: [ main ] pull_request: branches: [ main ] jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Set up PHP uses: shivammathur/setup-php@v2 with: php-version: '8.1' extensions: mbstring, intl, zip tools: composer - name: Install dependencies run: composer install --prefer-dist --no-progress --no-suggest - name: Run PHP_CodeSniffer run: vendor/bin/phpcs --standard=WordPress src/ - name: Run PHPUnit tests run: vendor/bin/phpunit --configuration phpunit.xml - name: Build artifact if: success() run: zip -r my-plugin.zip. -x "*node_modules*" "*tests*" "*.git*" - name: Upload artifact uses: actions/upload-artifact@v3 with: name: plugin-zip path: my-plugin.zip deploy: needs: build runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' && success() steps: - name: Download artifact uses: actions/download-artifact@v3 with: name: plugin-zip path:./ - name: Deploy via SSH uses: appleboy/scp-action@v0.1.3 with: host: ${{ secrets.SERVER_HOST }} username: ${{ secrets.SERVER_USER }} key: ${{ secrets.SERVER_SSH_KEY }} source: "my-plugin.zip" target: "/var/www/html/wp-content/plugins/" 

Обратите внимание на два важных момента:

• В блоке build мы проверяем код с помощью PHP_CodeSniffer и запускаем PHPUnit.
• Блок deploy активируется только после успешного билда и только из ветки main.

Шаг 3. Тестирование плагина в изоляции

Для надёжного CI рекомендуется запускать тесты в контейнере WordPress. Это можно реализовать через docker-compose:

version: '3.8' services: wordpress: image: wordpress:php8.1-apache ports: - "8080:80" environment: WORDPRESS_DB_HOST: db WORDPRESS_DB_USER: wp_user WORDPRESS_DB_PASSWORD: secret WORDPRESS_DB_NAME: wp_db volumes: -.:/var/www/html/wp-content/plugins/my-plugin db: image: mysql:5.7 environment: MYSQL_DATABASE: wp_db MYSQL_USER: wp_user MYSQL_PASSWORD: secret MYSQL_ROOT_PASSWORD: rootsecret volumes: - db_data:/var/lib/mysql volumes: db_data: 

В workflow добавьте шаг, который поднимает контейнеры и запускает тесты:

- name: Start Docker environment run: docker-compose up -d - name: Wait for WordPress run: | for i in {1..10}; do curl -s http://localhost:8080/wp-admin/install.php && break sleep 5 done - name: Run integration tests run: vendor/bin/phpunit --testsuite integration 

Такой подход гарантирует, что ваш плагин работает в реальном окружении, а не только в изоляции PHP‑unit.

Шаг 4. Автоматический деплой на продакшн‑сервер

Для продакшна часто используют SSH‑деплой или FTP. В примере выше мы использовали Git hooks WordPress‑подход, но с GitHub Actions это выглядит чище: артефакт передаётся напрямую на сервер, где скрипт распаковывает архив и активирует плагин.

Если ваш хостинг поддерживает только FTP, замените шаг Deploy via SSH на действие SamKirkland/FTP-Deploy-Action:

- name: FTP Deploy uses: SamKirkland/FTP-Deploy-Action@4.3.0 with: server: ${{ secrets.FTP_HOST }} username: ${{ secrets.FTP_USER }} password: ${{ secrets.FTP_PASSWORD }} local-dir:./ server-dir: /wp-content/plugins/ 

Шаг 5. Мониторинг и обратная связь

После того как pipeline настроен, полезно подключить уведомления в Slack или Telegram. Для Telegram можно воспользоваться готовым экшеном appleboy/telegram-action:

- name: Notify Telegram if: failure() uses: appleboy/telegram-action@master with: to: ${{ secrets.TELEGRAM_CHAT_ID }} token: ${{ secrets.TELEGRAM_BOT_TOKEN }} message: "❗ CI/CD pipeline failed for ${{ github.repository }}" 

Такой алерт позволит быстро реагировать на падения тестов и избежать «сломанных» релизов.

Оптимизация CI под нагрузку

Если ваш проект растёт, а CI начинает занимать часы, обратите внимание на подготовку WordPress к высокой нагрузке. Разделите workflow на несколько jobs (lint, unit, integration) и используйте кеширование Composer‑зависимостей:

- name: Cache Composer packages uses: actions/cache@v3 with: path: vendor key: composer-${{ runner.os }}-${{ hashFiles('composer.lock') }} restore-keys: | composer-${{ runner.os }}- 

Кеш ускорит последующие сборки, а параллельные jobs сократят общее время выполнения.

Заключение

Настройка CI/CD для WordPress плагина через GitHub Actions превращает рутинные задачи в полностью автоматизированный процесс. Вы получаете быстрый фидбек от тестов, гарантированную сборку артефакта и безопасный деплой на сервер. Интегрировав уведомления и кеширование, вы сможете поддерживать стабильность даже при росте проекта. Начните с простого workflow, а затем постепенно добавляйте шаги, опираясь на примеры из Edge Computing и аудит действий администраторов – это поможет держать код чистым и безопасным.