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

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

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

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

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

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

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

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

P.S. Я говорю о версии «Революции» MODX, если это имеет значение.

источник

2013-04-10 Alexander Surin

Я имею в виду способ развернуть только некоторые изменения не для всего проекта. В этом случае разработчик обычно имеет огромную БД на стороне производства и небольшую тестовую БД на локальной машине. Итак, какая часть базы данных должна быть скопирована и каков наилучший способ сделать это? Как насчет конфликта идентификационных данных при создании нового ресурса на DEV, и у него есть идентификатор, который уже занят PROD? –

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

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

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

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

ясно кэш !! деготь cvfz httpdocs.tar.gz httpdocs/ туздЫшпр -u -p the_database> export.sql

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

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

источник

2013-04-10 20:48:39

Кажется, вы объяснили, как сделать полную копию приложения. Но что делать, если у меня уже есть огромная независимая база данных на производственном сервере (например, пользовательский контент) и небольшая тестовая база данных на DEV? Также у меня может быть только одна учетная запись администратора с простым паролем для DEV и многих других учетных записей в PROD (для менеджеров, авторов и т. Д.) Я предполагаю, что в этом случае требуется частичное слияние баз данных, не так ли? Также как решить проблему с конфликтом ID ресурса? Если бы я сделал новую страницу на DEV, и я собираюсь переместить ее в PROD, у меня нет никаких гарантий того, что такой идентификатор по-прежнему остается незанятым там. –

Если вы собираетесь добавить ресурс или ресурсы, добавьте их в незарегистрированное состояние, если вам нужно сначала протестировать их на резервную копию производственных данных. Кроме этого, изменяются фрагменты, шаблоны, фрагменты, телевизоры, пользователь, роли, группы или политики. лучший выбор снова, тест на производственную копию, а затем реализовать. Как и в случае с чем-либо, проблема заключается в изменении данных в реальном времени во время разработки, если вам нужно вносить изменения из dev, вам придется прорываться через схемы xpdo, выяснить, какие таблицы могут/будут изменены и писать сами некоторые сценарии импорта/экспорта. –

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

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

https://github.com/digitalbutter/FEM

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

источник

2014-03-20 19:32:47 Liquinaut

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

ответ

Смежные вопросы