[ChangePack]-Компонент синхронизации копии сайта
Привет всем, сейчас разрабатываю сайт на MODx. Сайт делаю на локалхост, а затем копирую его в интернет. Сейчас, синхронизацию изменений, можно, делать sql-дампом. Но, скоро, сайт станет работать и, при этом, надо еще будет допиливать его. Стала задача забрасывать на рабочий сайт изменения, при этом не трогая его рабочие данные. Как, истинно, ленивый, решил это дело автоматизировать и написал компонент.
ChangePack
Компонент для синхронизации ресурсов и элементов локальной копии сайта на MODx с рабочей копией сайта.
Ведёт лог изменений ресурсов и элементов с флагом последних изменений (поле last). Лог доступен в Приложения->ChangePack.
На первой копии сайта, кнопкой «Зафиксировать изменения» в json-файл в папке «assets/components/changepack/commit» сохраняются измененные ресурсы и элементы.
На второй копии сайта, на вкладке «Применение коммитов и беккап» этот файл можно загрузить и применить.
Так можно, быстро, применить изменения от копии сайта разработчика на рабочий сайт.
При загрузке, создается файл беккапа старой версии ресурсов и элементов. Им, из меню таблицы беккапов, можно, откатить изменения.
github ChangePack
Компонент при применении коммита перезаписыват id нового созданного ресурса. В принципе, возможна ошибка c xpdo ссылками
ChangePack
Компонент для синхронизации ресурсов и элементов локальной копии сайта на MODx с рабочей копией сайта.
Ведёт лог изменений ресурсов и элементов с флагом последних изменений (поле last). Лог доступен в Приложения->ChangePack.
На первой копии сайта, кнопкой «Зафиксировать изменения» в json-файл в папке «assets/components/changepack/commit» сохраняются измененные ресурсы и элементы.
На второй копии сайта, на вкладке «Применение коммитов и беккап» этот файл можно загрузить и применить.
Так можно, быстро, применить изменения от копии сайта разработчика на рабочий сайт.
При загрузке, создается файл беккапа старой версии ресурсов и элементов. Им, из меню таблицы беккапов, можно, откатить изменения.
github ChangePack
Компонент при применении коммита перезаписыват id нового созданного ресурса. В принципе, возможна ошибка c xpdo ссылками
<composite alias="TemplateVarResources" class="modTemplateVarResource" local="id" foreign="contentid" cardinality="many" owner="local" />
<composite alias="ResourceGroupResources" class="modResourceGroupResource" local="id" foreign="document" cardinality="many" owner="local" />
<composite alias="Acls" class="modAccessResource" local="id" foreign="target" owner="local" cardinality="many" />
<composite alias="ContextResources" class="modContextResource" local="id" foreign="resource" cardinality="many" owner="local" />
Комментарии: 29
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Обновлено
И другой вопрос. Не проще ли сделать так, чтоб при нажатии кнопки на локалке, на боевом сразу применялись выбранные изменения не заходя на него и не загружая файл? Больше автоматизма. =) Например дать настройку, в которой будет указываться какой нибудь пароль, который необходим для выгрузки. А с локалки посылать этот пароль при отсылке изменений. Вроде безопасно.
Вообщем, если дорабатывать компонент, нужно довольно много продумать. Когда буду и буду ли вообще я этим заниматься пока неясно :).
Умная фраза :). С налета не поймешь, что это такое Gitify умеет делать и зачем он нужен. Да и в поиске modx синхронизация копий сайта Gitify не отсвечивал :).
Ладно это я несколько раздражен. Зацепила ваша фраза :).
Можно несколько поподробней как Gitify разрешает конфликты с Id.
Ничего не понятно. С честь чего «объект временно сохраняется в памяти». Мм… это понял — билд же делается. Схема работы: с базы локального сайта делается extract в файлы Gitify, файлы Gitify синхронизируются с репозиторием git, другой разработчик синхронизирует репозиторий git со своими файлами Gitify и делает билд данных в свою копию сайта.
Интересно :). Только как быть с рабочим сайтом, который находиться где-то на хостинге где есть только apache и ftp. Как его обновлять?
Не слишком приятно :(. В коде может ссылка на id ресурса. При изменении его id нужно править код.
В вашем случае с ваших же слов все прекрасно, пока вы работаете над сайтом один, но стоит только подключиться еще одному разработчику и все встанет. Тот же конфликт ID. Если вы делаете ссылку на id ресурса в коде, это перестанет работать, когда сайт перейдет в живой режим и не важно, какой инструмент синхронизации вы используете.
Ирония по поводу умной фразы в описании проекта меня изумляет, потому что, прежде чем давать оценки, стоит хотя бы попробовать инструмент. Gitify уже 2 года как успешно справляется с этой задачей. Его использует команда modmore, все мои сайты тоже синхронизируются через него. Так что да, я уверен в его возможностях, а чего не хватает – дописываю. Ну а уповать на то, что в гугле этот инструмент не ищется по запросу на русском языке, когда основной разработчик пользуется английским, ну я даже не знаю. Вроде и не глупо, но не дальновидно.
Разруливание конфликтов ID тема сложная и объяснить одним абзацем действительно проблематично, тем не менее на сейчас это наверное пожалуй самый адекватный алгоритм из существующих. Но и он не идеален, я без проблем это признаю.
Воспринимайте мой ответ, как конструктивную критику, а не как нападки. Я очень хотел бы видеть удобный инструмент синхронизации между сайтами, но уже на начальном этапе вижу проблемы в вашем решении. Хорошо, если получится их решить сейчас, в начале пути, когда есть еще время переделать.
Для текущих задач, ChangePack мне подходит. Работает как и задумывался. Хотя интересно сделать лучше. Можно выделять на каждую копию сайта пул id и после создания ресурса перезаписывать его id разрешенным id. Возможно подойдет для 2-5 разработчиков. Но это уже без «версионировать код через Git». Неясно будет ли компонент полезным. И захотят ли его, например, купить :). Сейчас буду текущим проектом заниматься. Дорабатывать нет времени.
По документации да, она не идеальна, над ней стоит поработать, я этим занимаюсь, но не всегда хватает времени сделать ее толково.
mysql
файлы
Таким же образом можно затягивать обновления с рабочего сервера. Генерация баш скриптов при создании сайта упрощает и написание этих строчек.
Компоненту, конечно, плюс. Управление с админки и дополнительные фичи с бекапом и выбором данных для синхронизации, то что нужно.
Работает через консоль.
Он умеет любую сущность, которая описана в schema дампить, нужно только package указать. C miniShop2 работает идеально. :)
Почитал оригинальную, вроде понятно, но не совсем. «Ключ» присваивается в качестве имени плейсхолдера или наоборот нужно взять существующий плейсхолдер и сформировать из него ключ. Опять же на инглише пример для селектора «да-нет» написан. А вот пример для смены фона шапки как сделать не разобрался(( не настолько я в этом деле опытен. Стоит ли вообще с ним заморачиваться без знания php? Потому как добавить возможность для группы пользователей менять шапку в своем «подотчетном» разделе — штука полезная и нужная. Но ее можно и через добавление TV сделать. Другое дело, что собрать все такие вот настройки в одну кучу — это здорово, но с моим уровнем знаний без примеров разобраться нереально(
Поэтому очень интересует существует такая информация в сети вообще или нет?
В шаблонах и чанках вызываются так: [[+key]]
В php вызывается так: $modx->getOption('key');
Идея хорошая, но в процессе выплывает очень много подводных камней. По этой причине советую прислушаться к Ивану и заранее продумать вопросы, связанные с ID и несколькими разработчиками.
Сюда же, кстати, можно отнести и вариант попутной разработки отдельных компонентов, которые нужны для проекта, но предполагаются для дальнейшего массового распространения. Необходимо сразу предусмотреть вариант разделения проекта на отдельные составляющие.
Заодно уж: Иван, расскажи, пжл, насколько Gitify подходит для поддержки одновременно нескольких рабочих серверов?
Fi1osofТаких подводных камней бесчисленное множество. По этой причине, создавая инструмент переноса данных, необходимо сразу определиться с некоторыми условностями. Например, запретить изменение username пользователям, не переименовывать TV после отправки по другим сайтам и тд.
Ресурсы можно тоже легко и успешно переносить между сайтами, изменять их содержимое, здесь вариантов 2:
1) В самом ресурсе определить поле, которое не изменяется ни при каких условиях
2) Создать отдельную таблицу, в которой будет сохраняться соответствие ресурса и дополнительного служебного кода этого ресурса. Кстати, мой синхронизатор стоит дополнить вторым механизмом, получится более красивая и удобная вещь.
Fi1osofЧто касается идеального варианта, единственный способ сделать универсально — задать какие-то минимальные рамки, соблюдения которых требовать от всех разработчиков, которые выберут твой инструмент для работы. А дальше решение уже за ними — если соблюдают, то все хорошо и корректно переносится. Если нарушают требования, то иногда получают непредсказуемый вариант.
При этом, синхронизатор должен иметь несколько режимов работы. Как минимум:
1) Управление копиями через мастер-сервер
2) Выгрузка обновлений с тестового сервера на рабочий (-е).
Если же мы говорим о работе и изменениях непосредственно на рабочем, например, как в твоем случае, то здесь вообще синхронизатор не нужен. Достаточно простого протоколирования изменений.
P.S. Не могу найти собранный пакет, раньше вроде был в репозитории… Где-то на сайтах у меня остался он ещё, вроде было удобно)) Давно не пользовался, сейчас вроде актуальность появилась, хочу вот уточнить у первоисточника, как дела с миграциями изменений в БД?
Включил в модсторе changepack. Если надо пользуйтесь.
Уже сделал fork и помучал его вчера: github.com/dimasites/revo-changepack но почему-то пока н решил проблему с подстановкой правильной ссылки на скачивание JSON и главное — ошибку при загрузке «коммита» из файла ли соответственно не проверил как применяются изменения).
Если у тебя будет минутка, может опытным взглядом увидишь в чем проблема...?
И 2й вопрос: могу ли использовать часть кода компонента в каком-то новом решении? С сохранением копирайтов твоих само собой.
Есть идея сделать некий githelper или gitmanager, ещё один, ага) Но более UI-шный и скажем так, сответствубщий тому, как видится современный workflow работы с modx на более-менее ответственных проектах я где нужна страховка и возможность отката изменений…
Без проблем. И даже копирайты не обязательно.
Проблема в том, что MODX хранит чанки, сниппеты и т.д. в базе. К базе просто так гит не подключишь и сделать синхронизацию сложно. Сейчас я пишу компоненты в которых все до установки в файлах и использую обычный гит. И версии изменений есть и обновить боевой сайт не проблема. И githelper не нужен.
Хранит то modx чанки и шаблоны и т.п. в базе да, но с ними как раз нет проблем — сталь галочку Статичный, указываешь папку и файл е лежит код — и вот уже код хранится не в базе данных, а в файле, и можно версионировать его через git. Пишу это не для тебя ;) а скорее для читателей, которые все ещё верят в миф про то, что в modx есть какие-то проблемы есть с git-ом.
Проблем с git нет вообще! Разве что, для упрощения быстрого старта по умолчанию сохранение кода в файлы в системных настройках не включено, пожилому он и знания в БД пока не поставишь галочку или не включишь сис. настройки (staticelements что-то там такое в префиксе)…
Я использую так уже почти 10 лет. А слабое звено тут получается контент, хранящийся в базе, и вот тут будет удобно использовать что то вроде ChangePack, для автоматической генерации файла с «миграцией» изменений в БД.