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

Question

[Александр Епихин]

Хочу настроить удобный и автоматизированный процес по созданию, деплою и поддержки сайтов на 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

Очень хотелось бы услышать пожелания и советы по улучшению.
Также хочется узнать как это делают другие.

Comments

[alex-1917]

вы клепаете по 300 сайтов в сутки?...)))

[Александр Епихин]

alex-1917, нет

[yarovikov]

Вышеописанный вариант подразумевает расположение сайтов заказчиков на вашем сервере.

[lamer350]

А как вы собираетесь править на лету конфиг и БД при каждой синхронизации?
Ладной конфиг вы один раз переделать и добавить в игнор, но WP в базе хранит абсолютные пути к папкам, sitename, в зависимости от плагинов установленных - так же могут быть ссылки не относительные, а абсолютные с sitename.
К тому же надо учитывать что еще ссылки есть с екранированием и без...
И мое любимое - слет настроек CF7 последних версий при переносе БД, уже сталкивался на 3х сайтах из 5 за эти пару месяцев, так и не понял причину, не было времени разобраться :/

[Александр Епихин]

yarovikov, да, я понимаю это

[Александр Епихин]

lamer350, я использую bedrock там настройки в .env файле лежат. Его можно подменять с помощью Ansible template .
Все пути везде одинаковые. Отличия в урлах только в домене (loc, dev, ru, com) и в протоколе (http, https).

[Дмитрий]

lamer350, настройки слетают тк в базе настройки хранятся в сеаризиванном виде
поэтому простая замена путей с local на site.com их ломает
пользуйтесь wp-cli или плагинами для экспорта базы с правкой путей

[Александр Епихин]

Дмитрий, вы видимо мне отвечали. Понял. Спасибо.

[Дмитрий]

leshiple, не не, это было тому пользователю вот про это

И мое любимое - слет настроек CF7 последних версий при переносе БД

но вам такое тоже пригодится
https://developer.wordpress.org/cli/commands/searc...

[justvlad]

И это всё ради ГС на WordPress? 3 сервера, чтобы развернуть один бложик? Зачем? Это шутка что ли или троллинг?

[Александр Епихин]

justvlad, Да. Это не бложики. Лень делать руками. Не шутка и не троллинг.

[Игорь Воротнёв]

justvlad, О, еще один. А почему сразу бложик? Вы о**еете, когда увидите реальные боевые сайты на WP, сложность и объемы которых сильно превышают всё, что ваши глаза когда либо видели. И это абсолютно живые, качественные проекты, которые приносят кучу бабла. И да, там все современные и няшные штуки типа composer, CI и тд.

Answer 1

[Игорь Воротнёв]

В целом все ок, разница всегда будет в каких-то нюансах. В зависимости от типа проекта, нюансов будет больше или меньше. У нас плюс-минус так:

- Локальная разработка на 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 на продакшн. Но ситуации и проекты бывают разные, здесь нет одного правильного ответа.

Answer 2

[Дмитрий]

вам достаточно в ваш воркфлоу добавить wp-cli
это значительно упростит алгоритм и не будет необходимости что-то кардинально менять

Comments

[Александр Епихин]

Буду признателен если вы опишите предлагаемый алгоритм деплоя

[Дмитрий]

пропустил, WP-cli у вас уже есть.

тогда коротко, что у вас не как у всех.
самое главное отличие вашего - везде всегда база идет вниз, а код вверх. базу с стейджингов на проду не копируют никогда.
ваш деплой подходит для редкообновляемых сайтов или для работы одному. На более крупных проектах за время добавления фичи в базу 100% накидают кучу новых постов.

[Александр Епихин]

Спасибо. Проекты в основном одностраничники. Можно заморозить обновление контента. Часто случается такое что нужно добавить весь контент перед показом на сайте. Например нужно вывести комплектации авто. В процессе добавления случается много ошибок в тексте. Поэтому делаем сначала на dev/stage, а потом выгружаем в готовом виде на production. Как тут можно сделать чтобы не дергать базу вверх?

[Дмитрий]

leshiple, возможно вам больше подойдет не WordPress, а какой-нить Jekyll, Gatsby или другой генератор статических сайтов

[Игорь Воротнёв]

Дмитрий, WordPress - точно такой же генератор статических сайтов, только удобнее, и проще реализовать сам процесс генерации.

[Александр Епихин]

Дмитрий, я бы и рад, но не всегда это статика. Иногда требуется подмена контента в зависимости от utm меток. И киллер фича WP для меня это GUI кастомных полей в виде плагина ACF