Как вы разрабатываете и поддерживаете сайты на Worpdress?

Хочу настроить удобный и автоматизированный процес по созданию, деплою и поддержки сайтов на WP.
Ниже опишу как я себе это представляю.
Вся автоматизация производится с помощью Ansible

Имеем 3 сервера:
development - это линукс запущенный в virtuabox на локальной машине разработчика
staging - сервер на хостинге на который будут выгражаться сайт/изменения перед выгрузкой на production
production - это боевой сервер с которого сайт и будет доступен.
Серверы имеют одинаковую конфигурацию, которая настраивается с помощью Ansible.

На каждом сервере по 2 пользователя:
admin - с правами суперпользователя. Он нужен для конфигурирования и администрирования сервера
developer - без прав суперпользователя. Он нужен для вугрузки сайта/изменений на сервер.

Шаги создания нового сайта:
1) С помощью CLI вводятся название сайта, url (единственный шаг ручной, остальное выполняется автоматически)
2) Создается GIT репозиторий
3) Создается Nginx/Apache host на каждом сервере
4) Создаются базы данных, на development сервере - 1, на staging и production по 3 (active, inactive, wait).
5) Разворачиваются копии Wordpress с помощью wp-cli на каждом сервере.
6) Готово.

На production и staging серверах делаются бекапы кода, изображений и плагинов и баз данных перед каждым деплоем.
На сервере бэкапы(релизы) хранятся за последние две недели.
host root с помощью ссылки указывает на необходимую директорию релиза.
Остальные бэкапы хранятся в Яндекс.Диске, который подключен через WebDAV.

Шаги полного деплоя (файлы проекта и база данных ) на production/staging:
1) На development сервере создается дамп базы данных и архив со всеми файлами проекта
2) На production сервере делается бэкап всех файлов, создается дамп базы данных active (та база которая измользуется на сайте), все это кладется в директорию releases и в облако
3) На production копируются файлы проекта с development и распаковываются в директорию releases и ссылка host root указывает на директорию данного релиза
4) Дамп базы данных с development импортируется в базу данных с именем wait на production сервере.
5) На production сервере база данных active переименоввывается в inactive
6) На production сервере база данных wait переименоввывается в active
7) Готово

Не очень нравится чехарда с переименовыванием баз данных. Есть идея иметь 2 базы данных и переключаться между ними с помощью wp-config

Очень хотелось бы услышать пожелания и советы по улучшению.
Также хочется узнать как это делают другие.
  • Вопрос задан
  • 1095 просмотров
Решения вопроса 1
HeadOnFire
@HeadOnFire
PHP, Laravel & WordPress Evangelist
В целом все ок, разница всегда будет в каких-то нюансах. В зависимости от типа проекта, нюансов будет больше или меньше. У нас плюс-минус так:

- Локальная разработка на macOS + Laravel/Valet (Nginx, PHP 7+, MariaDB, Redis/Memcached).
-Staging/production могут быть как отдельными серверами, так и находиться на одном сервере, а также могут быть много сайтов на одном сервере, или это может быть не наш сервер, а какой-нибудь Kinsta или вообще клиентская инфраструктура к которой у нас доступа нет. Поэтому devops кухня вообще отделена. С нашей стороны только автодеплой из репы через CI/CD. Ветка develop -> staging, ветка master -> production.
- WordPress, плагины, тема, и весь кастомный код являются зависимостями проекта, управляется с помощью Composer.
- Работа с функциональностью WordPress строится полностью на командной строке с помощью WP-CLI. При необходимости пишутся свои команды для него.
- Вся конфигурация проекта в .env (база, ключи, лицензии и прочее, что не попадает в git) и в папочке config в виде PHP-конфигураций (все что уже влияет на функциональность).
- Медиа-файлы на локалке либо вообще не хранятся (Valet проксирует запросы на staging/production), либо синхронизируются со staging/production. Делается это с помощью отдельного cli-скрипта, который под капотом использует rsync.
- Базы данных - отдельная история которая очень сильно зависит от специфики проекта. Где-то это простой push/pull с помощью WP Migrate DB, где-то тот же push/pull c помощью WP-CLI, где-то это целые миграции. В идеале надо стараться контент забирать с прода на стейдж и избегать публикации с dev/staging на продакшн. Но ситуации и проекты бывают разные, здесь нет одного правильного ответа.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
dimasmagadan
@dimasmagadan
вам достаточно в ваш воркфлоу добавить wp-cli
это значительно упростит алгоритм и не будет необходимости что-то кардинально менять
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы