Каков наилучший способ развертывания при использовании MODX?

Это удобно, когда у вас есть РАЗРАБОТКА версия приложения на вашем локальном компьютере, и вы можете развернуть ее на сервере STAGE для тестирования (это необязательно), а затем развернуть на сервере PRODUCTION. Вы можете сделать это относительно легко, когда в проекте есть четкое усмотрение кода и данных (например, если мы храним весь код и настройки в файлах проекта, а данные в базе данных).

MODX хранит шаблоны, сниппеты и т. Д. В базе данных. Да, мы можем переместить этот код в статические файлы, а затем использовать систему контроля версий для отслеживания изменений этих элементов. Но у этих тоже есть репрезентативные строки в базе данных. Это означает, что мы должны обновлять базу данных, как и раньше, если мы добавили или удалили некоторые элементы.

Похоже, у нас также могут возникнуть проблемы, если мы просто скопируем файлы расширений вместо того, чтобы производить установку с помощью диспетчера пакетов (потому что расширения часто имеют свои собственные таблицы в БД).

Другая проблема заключается в том, что приложения на DEV и PROD имеют разные настройки, хранящиеся в файлах (конфигурациях) и базе данных (например, учетные записи пользователей).

Я до сих пор не вижу четкого способа организации итеративного цикла разработки DEV-STAGE-PROD. Итак, мои вопросы:

  • Какие файлы и таблицы базы данных я должен (или должен) копировать при развертывании?
  • В каком режиме (заменить, игнорировать) я должен это делать?
  • Как это сделать проще и быстрее всего?

Меня больше всего беспокоит работа с базой данных.

P.S. Я говорю о "Revolution" версии MODX, если это важно.


person Alexander Surin    schedule 10.04.2013    source источник
comment
Я имею ввиду способ развёртывать только некоторые изменения, а не весь проект. В этом случае разработчик обычно имеет огромную БД на производственной стороне и небольшую тестовую БД на локальной машине. Итак, какая часть базы данных должна быть скопирована и как лучше всего это сделать? Как насчет конфликта идентификаторов ресурсов, когда вы создаете новый ресурс на DEV, и у него есть идентификатор, который уже занят на PROD?   -  person Alexander Surin    schedule 11.04.2013


Ответы (2)


База данных не должна хранить никакой информации о пути вообще, в предыдущих версиях это было в таблице modx_workspaces, но с тех пор она исчезла [я полагаю, что это версия 2.2.4].

Если вас беспокоит изменение URL-адреса [dev.mysite.com / stage.mysite.com / production ...], не беспокойтесь - все это находится в файле .htaccess [раньше была системная настройка site_url, но он, кажется, тоже исчез.]

Единственный файл, о котором вам нужно беспокоиться, - это core / config / config.inc.php ~ создать 3 разных файла с разными путями или просто заменить их при миграции.

мой процесс перемещения / обновления / миграции сайтов modx:

очистить кеш !! tar cvfz httpdocs.tar.gz httpdocs / mysqldump -u -p база_данных> export.sql

переместите файлы, tar xvfz и импортируйте базу данных. Рекомендуется проверить таблицу modx_workspaves, и если вы использовали старую версию галереи, проверьте и это, но большинство плагинов и разработчиков, похоже, привыкли НЕ хранить информацию о пути в таблицах кода и БД.

Конечно, если вы усилили свою установку, есть еще несколько шагов, но ничего серьезного. [см. «статью об усилении защиты Modx на сайте rtfm.modx.com]

person Sean Kimball    schedule 10.04.2013
comment
Похоже, вы объяснили, как сделать полную копию приложения. Но что, если у меня уже есть огромная независимая база данных на производственном сервере (например, пользовательский контент) и небольшая тестовая база данных на DEV? Также у меня может быть только одна учетная запись администратора с простым паролем для DEV и многих других учетных записей на PROD (для менеджеров, авторов и т. Д.). Я полагаю, в этом случае требуется частичное слияние баз данных, не так ли? Также как решить проблему с конфликтом идентификаторов ресурсов? Если я создал новую страницу на DEV и собираюсь переместить ее в PROD, у меня нет гарантий, что такой идентификатор там еще не занят. - person Alexander Surin; 11.04.2013
comment
Если вы собираетесь добавить ресурс или ресурсы, добавьте их в реальном времени в неопубликованном состоянии, если вам нужно сначала протестировать их, работая с резервной копией производственных данных. Помимо этого, изменение фрагментов, шаблонов, блоков, телевизоров, пользователей, ролей, групп или политик. Лучше всего снова протестировать на производственной копии, а затем внедрить. Как и во всем, проблема заключается в том, что данные в реальном времени меняются во время разработки, если вам нужно внести изменения из dev, вам придется копаться в схемах xpdo, выяснить, какие таблицы могут / будут изменены, и написать самостоятельно некоторые скрипты импорта / экспорта. - person Sean Kimball; 11.04.2013

Я думаю, что вы ищете этот плагин (в зависимости от вашей версии modx):

https://github.com/digitalbutter/MODX-Mirror

https://github.com/digitalbutter/FEM

Все чанки, сниппеты и т. Д. Находятся на диске. Любые изменения, внесенные в файлы, вызовут соответствующие изменения в базе данных без необходимости выполнять полный импорт / повторный импорт SQL. Это позволит использовать любую систему контроля версий / распределенную среду разработки / автоматическое развертывание.

person Liquinaut    schedule 20.03.2014