Как деплоить правки?

Question

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

Как выгружать на сервер правки которые затрагивают код и базу данных?
Например вы изменили на странице какой-то блок, поправили код, в админке изменили контент.
Теперь это все нужно выгрузить на сервер. Код без базы работать не будет, блок который вы правили будет коряво отображаться. И наоборот новая версия базы не будет нормально работать со старым кодом. Да и полностью базу нельзя обновлять, так как с момента создания дампа, в продакшен базу внесли изменения (добавили новые статьи, новые комментарии). В ручную повторно вносить изменения в базу на продакшене не очень хочется.
Получается нужно практически одновременно (с минимальным интервалом) выгрузить новый код и базу (только то что изменилось).
Как вы решаете данный вопрос? Как автоматизируется deploy новых фич проекта?

Comments

[Sergey]

Очень просто и в тоже время сложно - не использовать wordpress

[Alex]

Sergey, Ох, если бы всегда можно было выбирать с чем работать а с чем нет ...

Answer 1

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

Во-первых, запомнить раз и навсегда 2 простые истины:

1. Продакшн база данных должна быть только на продакшне и больше нигде. Эти данные нельзя as-is использовать локально - в том числе по причинам юридическим и privacy (привет логины-пароли клиентов, их персональные данные и тд). Грубо говоря, за это можно и пострадать.
2. Локальная / development база данных работает только с тестовыми / посевными данными.

Между ними никакой синхронизации не должно быть, никогда. От слова совсем. И WordPress тут вообще ни при чем - эта проблема существует и в Laravel, Symfony, Ruby on Rails и тд. Просто там с нуля сразу учат решать ее правильно. Впрочем, продакшн-данные можно (и даже нужно) использовать как пример для генерации локальных данных. Например, в production БД можно посмотреть какие реальные first name и last name используются юзерами, чтобы улучшить валидацию и/или отображение.

Как с этим жить?

1. Для переноса изменений структуры базы данных используются миграции. В WordPress для этого есть dbDelta().
2. Для переноса посевных данных используются посевы (seeds). Например, если нужно залить список терминов в глоссарий (custom taxonomy), заполнить список отделов компании и тд - все это сеется.
3. Все остальное (настройки мышкой в админке, добавление контента и тд) делается руками. Локально вы вообще не должны даже думать о том, чтобы создавать какие-то страницы 1 в 1 с рассчетом на то, что потом будете их как-то "синхронизировать" на боевой сервер. Это в корне неправильный mindset, который и привел вас к этой проблеме. На локальной версии вы все тестируете с тестовыми данными. Даже если вы не используете lorem ipsum, а вставляете реальный текст предоставленный клиентом - это все равно тестовые данные.
4. Чтобы сайт не ломался в процессе выкатывания изменений (когда код залили, а контент еще делается) код нужно писать с учетом этой логики (опять же - дело в mindset). Например, есть такое понятие как feature flags, есть function_exists(), есть isset(). Ваш код должен работать корректно всегда - например, если данные для какого-то блока не заполнены, то блок не выводится вообще.

Answer 2

[Александр]

разработка на wordpress с git

Comments

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

Спасибо, если я правильно понял там полностью заменяют базу. Это не подходит.

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

Крайне вредная статья, демонстрирующая как делать не надо. Неправильное использование инструментария не сильно лучше неиспользования оного вообще.

Answer 3

[Sergej]

Envoy, deployer etc...
Автоматически из репы создается новая версия и обновляется ссылка.
В БД лезть вообще не надо руками
Если добавили поле/таблицу и т.п., это делается через миграции

Можно конечно настроить какие то реплики данных.

Естественно все должно быть протестировано компетентными людьми на дев сервере.

Comments

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

Как это применить к Wordpress?
В большинстве правок меняется не структура базы. Она заранее предопределена.
Добавляются только строки со значениями.
В случае если есть произвольные поля по таблица wp_postmeta может иметь такой вид https://yadi.sk/i/CDdybN5IgAlipA
В ручную писать команды для миграции в этом случае не очень удобно и долго. И в итоге процесс подгтовки миграции будет занимать больше по времени чем сама правка. Что я считаю не целесообразно.

[Sergej]

Александр Епихин, я бы все равно делал через миграции. Как? Это уже другой вопрос над которым надо думать.
Я WP не селен и по этому не знаю что это.

Но судя по данным, это какие то элементы интерфейса которые располагаются в БД, что естественно не верно. Данные на дев и прод могут и скорее всего будут разные. В в БД не должны быть элементы интерфейса.
Как разработчик, вы меняете код, данными управляете тоже при помощи кода.

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

Верно это или не верно это холиварный вопрос.
Есть задача, я прошу подсказать пути ее решения.
Миграции это хорошо, но дело в том что писать их вручную для подобной каши слишком долго. Нужно средство для автоматизации.

[Sergej]

Александр Епихин, если данные одинаковы или с дева должны попасть на прод, то можно в деплое написать команду, которая будет делать дамп и заливать его на сервер.
Или генерировать миграцию с нужными инсертами.

Как вариант, в IDE можно нажать синхронизацию БД.
Других вариантов подсказать на данном этапе не могу.
Это надо думать, к тому же понимать что и как должно обновляться, структуру вашего окружения.

Дело не в холиваре а в лишних проблемах и действиях которые приходится выполнять разработчику.

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

Что это лишние действия я с вами полностью согласен.
Но мне не известна CMS где можно было бы создавать произвольные формы (с вложенными полями) для редактирования контента в админ панели и вопрос миграции был бы простым.

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

Александр Епихин, вы смотрите на свой скриншот и не видите очевидной проблемы. Числа, которые в вашем рипитере ACF (intro_slides_X_img), это ID записей типа attachment в таблице wp_posts. WordPress не знает о существовании такой штуки как foreign key check, и проблема в том, что на живом сайте эти же ID уже могут быть заняты записями вообще другого типа. Это одна из глобальных проблем out of sync data при работе с более чем 1м экземпляром базы. Так делать не нужно. Смотрите мой ответ ниже.

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

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

и вопрос миграции был бы простым

Вы путаете термины. Миграции - это про структуру. Это просто. Про контент - это посев.

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

Никогда не слышал про "посев". Спасибо, теперь буду знать.

Answer 4

[Дмитрий Шицков]

Обновление базы накатывается и откатываться миграциями. Механизмов и инструментов миграций предостаточно, можно выбрать подходящий.
Миграции можно катить как с кодом, так и отдельно.
Существует одно полезное правило, которым любят пренебрегать - код должен поддерживать базу версий v и v-1. Миграция так же не должна ломать совместимость кода v-1 при накатаке. В таком случае можно говорить о безопасной выкатке новой версии, и безопасном способе откатываться.

Comments

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

Покажите пожалуйста пример миграций для Wordpress

[Дмитрий Шицков]

Александр Епихин, Например
https://book.cakephp.org/phinx/0/en/index.html
=
https://github.com/beezee/wp-phinx

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

С таким же успехом вы могли прислать ссылку на любой другой инструмент для миграций. Но это никак не раскрывает решение проблемы. Что есть миграции я знаю. Но я не знаю как их писать для Wordpress и как это можно автоматизировать.
У вас есть пример миграции для Wordpress которая не просто перезатирает старую базу данных?

[Дмитрий Шицков]

Александр Епихин, что значит "перезатирает"? Это не миграция какая-то. это дамп.
И чем Wordpress особенный? Чем он отличается от любого другого PHP-сервиса?

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

Он отличается способом хранения значений в базе. Вот пример одной из таблиц. https://yadi.sk/i/CDdybN5IgAlipA
Значение в колонке meta_key генерируется автоматически плагином ACF Pro. Где intro_slides_0_desc это путь к вложенному полю в JSON представлении путь записывался бы как intro.slide[0].desc. И таких полей очень много. Выбирать их вручную и для каждого писать insert это не выход.

[Дмитрий Шицков]

Александр Епихин, т.е. ваш вопрос про миграцию данных, а не структуры?
То что данные хранятся как говно я понял, а во что это всё смигрировать должно, какие изменения необходимы, как пример?

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

Да

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

Структура в Wordpress меняется только если установить какой-то плагин или сознательно это сделать.
Миграции должны создаваться автоматически на основе diff баз

[Alex]

А вот я с миграциями не знаком. Не могли бы вы рассказать как это будет работать?
Предположим такая ситуация:

• Я сделал копию продакшена себе на локалку. Все файлы и БД. Внес какие-то изменения в код. Установил новый плагин и включил его. Включение и отключения плагинов затрагивает существующую таблицу в БД. А сам плагин при активации создаёт новую таблицу для собственных нужд.
  
• В это время, на проде, пришли пользователи и написали несколько комментариев к постам. Понятное дело все коменты добавляются в БД.
  

Так вот, как мне "слить" изменения в сайте на прод, не стерев при этом новые комментарии?

[Дмитрий Шицков]

Александр Епихин, если есть база на основе которой можно сделать "diff" – звучит просто.
Берем базу №2 и всю ее инсертим в старую. При конфликтах ничего не делаем.
Реальный diff получить не получится, так как база живая и изменяется.

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

Alex миграции позволяют с помощью кода производить манипуляции с базой.
В вашем случает вам придется написать php скрипт в котором будет использоваться какой-нибудь инструмент для миграций (например phinx).
Используя функции phinx (create, inset и т.п.) вам нужно будет вручную написать команды которые создадут новую таблицу, вставят новые данные в существующие таблицы. Т.е. написать код который изменит вашу базу так как это сделал плагин.