Современные методы разработки позволили в целом решить проблему с файлами. Мы используем Git для версионирования наших тем и плагинов, а также конвейеры CI/CD для развертывания этих файлов в тестовой и производственной средах. Но для многих команд база данных остается крайне проблемным узким местом, требующим ручной работы.
Независимо от того, передаете ли вы данные с продакшна в локальную среду для отладки или загружаете новую структуру полей ACF в тестовую среду, полагаться на ручной экспорт и импорт SQL — это верный путь к катастрофе. Эти процессы медленны, подвержены человеческим ошибкам – это самый распространенный способ повреждения сериализованных данных.
Для профессионального развертывания необходимо автоматизировать уровень базы данных. Именно здесь на помощь приходит интеграция WP Migrate с WP-CLI.
Почему недостаточно применять wp db export
Многие разработчики начинают с использования встроенных команд wp db export и wp db import. Хотя они отлично подходят для простого резервного копирования, они опасны при миграции между средами.
Основная причина — сериализованные данные. WordPress часто хранит сложные данные (например, настройки виджетов или конфигурации ACF) в виде сериализованных PHP-объектов. Если вам нужно скорректировать длину строки (например, изменить http://localhost на https://production.com), стандартный поиск и замена в SQL нарушат сериализацию, и данные просто исчезнут с фронтенда.
В отличие от стандартных SQL-запросов, которые обрабатывают базу данных как плоский текстовый файл, фоновая логика WP Migrate выполняет поиск и замену на уровне PHP. При выполнении миграции плагин идентифицирует сериализованные данные и временно десериализует их для выполнения замены строк в фактической структуре данных. После обновления строк он повторно сериализует данные и автоматически пересчитает внутренние значения длины строк перед сохранением их в целевой базе данных. Этот процесс гарантирует сохранность метаданных, даже если новый URL-адрес сайта имеет совершенно другое количество символов, чем старый.
Мост: профили миграции
На этом этапе вы можете начать запускать команды в терминале, но, вероятно, лучше сначала создать профиль миграции. Профили миграции — это специализированная функция WP Migrate для управления сложными конфигурациями.
Профили миграции — это, по сути, сохраненные пресеты для вашей миграции. В пользовательском интерфейсе WP Migrate вы определяете:
- Какие таблицы включить или исключить.
- Конкретные пары поиска и замены.
- Следует ли синхронизировать медиатеку или файлы темы.
Определив эти параметры в пользовательском интерфейсе, вы избежите головной боли, связанной с передачей десятков сложных аргументов в терминале. Далее CLI сможет запустить всю логику этого профиля, используя один идентификатор.
Выборочная синхронизация таблиц: защита продакшна
Самый главный риск в автоматизации БД связан с операцией «push», когда вы перемещаете данные из базовой среды (например, локальной или тестовой) на рабочий сервер (продакшн). Если вы перенесете всю базу данных, над которой работали несколько дней, вы перезапишете live-сайт устаревшими локальными данными, потенциально уничтожив все заказы или регистрации пользователей, которые произошли во время разработки.
В этом случае выборочная синхронизация становится обязательной мерой безопасности. Вместо подхода «всё или ничего», интеграция WP Migrate с WP-CLI позволяет вам действовать точечно. В вашем профиле миграции следует настроить конкретные исключения для транзакционных таблиц:
- wp_users и wp_usermeta
- wp_comments
- wp_posts и wp_postmeta (особенно если вы хотите синхронизировать только настройки/структуру, а не контент)
Исключив эти таблицы, вы сможете обеспечить структурную отправку, которая перенесет новые группы полей ACF или конфигурации плагинов в продакшн без кошмарного сценария удаления данных клиентов.
Автоматизация с помощью секретных ключей
WP Migrate использует секретные ключи для авторизации. Это означает, что вам не нужно задавать сложные SSH-туннели только для перемещения данных. При настройке конвейера CI/CD (например, GitHub Actions) следует хранить эти учетные данные в виде секретов, привязанных к окружению, в вашем CI/CD-провайдере (например, GitHub Actions или GitLab CI).
Ограничивая доступ к секретам только производственной средой, вы можете реализовать правила защиты, например, требовать ручного подтверждения перед внедрением секретов в рабочий процесс. Это гарантирует, что отправка данных в БД на вашем продакшне произойдет только после того, как старший член команды подтвердит развертывание.
Практическое применение: фрагмент кода GitHub Actions
Вот как можно автоматизировать отправку Pull request для внесения на тестовый сайт данных с подакшна всякий раз, когда ставится метка нового релиза.
jobs:
db-refresh:
runs-on: ubuntu-latest
steps:
- name: Trigger WP Migrate Pull via SSH
uses: appleboy/ssh-action@master
with:
host: ${{ secrets.STAGING_HOST }}
username: ${{ secrets.STAGING_USER }}
key: ${{ secrets.SSH_PRIVATE_KEY }}
script: |
# Navigate to the site root and trigger the saved profile
cd /var/www/html
wp migrate pull 5 --path=/var/www/html
В этом примере число 5 обозначает конкретный идентификатор профиля миграции, созданного в пользовательском интерфейсе WP Migrate. После того как вы определите свой идентификатор с помощью команды wp migrate profiles list, CLI автоматически выполнит аутентификацию, поиск и замену на уровне PHP, а также исключит заранее заданные таблицы. Это позволяет сохранить чистоту скрипта развертывания, поскольку основная настройка выполняется в самом профиле.
Источник: https://deliciousbrains.com
