[ChangePack]-Компонент синхронизации копии сайта

Привет всем, сейчас разрабатываю сайт на MODx. Сайт делаю на локалхост, а затем копирую его в интернет. Сейчас, синхронизацию изменений, можно, делать sql-дампом. Но, скоро, сайт станет работать и, при этом, надо еще будет допиливать его. Стала задача забрасывать на рабочий сайт изменения, при этом не трогая его рабочие данные. Как, истинно, ленивый, решил это дело автоматизировать и написал компонент.

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" />
Например, может, потеряться значение tv параметра. Или, может, точнее, появиться лишнее значение параметра tv. Не связанное с ресурсом. Мне, сейчас, не удалось получить ошибку такого типа. И врядли она у меня появиться. Думаю, через месяц два напишу новую версию с пулом id для каждой копии сайта, чтоб такие коллизии в принципе исключить :)
Александр
19 декабря 2015, 06:30
modx.pro
10
3 382
+11
Поблагодарить автора Отправить деньги

Комментарии: 24

Павел Гвоздь
19 декабря 2015, 09:46
+2
Классно. И сразу вопрос. Что с настройками, пакетами, неймспейсами, контекстами и другим, чем богат MODX?

Обновлено
И другой вопрос. Не проще ли сделать так, чтоб при нажатии кнопки на локалке, на боевом сразу применялись выбранные изменения не заходя на него и не загружая файл? Больше автоматизма. =) Например дать настройку, в которой будет указываться какой нибудь пароль, который необходим для выгрузки. А с локалки посылать этот пароль при отсылке изменений. Вроде безопасно.
    Александр
    20 декабря 2015, 03:18
    0
    Ну лучшее враг хорошего. Сейчас мне пока такого хватает. Потом можно допилить. При закидывании на боевой сайт, Id ресурса перезаписывается. Если на боевом сразу кто-нибудь ресурсы создает, возникнет конфликт. У меня пока только я создаю новые ресурсы, и мне только следить, чтобы одновременно не писать на боевом и тестовом.
    Вообщем, если дорабатывать компонент, нужно довольно много продумать. Когда буду и буду ли вообще я этим заниматься пока неясно :).
      Иван Климчук
      20 декабря 2015, 14:50
      0
      Поробуйте Gitify, там все уже есть :)
        Александр
        20 декабря 2015, 16:21
        0
        Не факт ;). По задумкам, возможно, у меня бы получилось лучше :). Но пока Gitify не ставил. Еще не понятно как он работает. Документация на русском пока не айс.
        Цель Gitify — обеспечить двунаправленную синхронизацию данных, обычно хранящихся в базе данных MODX, что позволит версионировать код через Git.
        Умная фраза :). С налета не поймешь, что это такое Gitify умеет делать и зачем он нужен. Да и в поиске modx синхронизация копий сайта Gitify не отсвечивал :).
        Ладно это я несколько раздражен. Зацепила ваша фраза :).
        Можно несколько поподробней как Gitify разрешает конфликты с Id.
        Так же с версии 0.9 Gitify build автоматически пытается решить проблему дублирования id и первичных ключей для контента и других объектов. Когда находится объект, первичный ключ которого (обычно это ID) уже существует, этот объект временно сохраняется в памяти. После полного завершения остальной сборки, включающей очистку, будет произведена попытка разрешить этот конфликт. В случае перемещения или переименования объекта/ресурса, благодаря очистке «старый» объект будет удален, в результате чего новый будет вставлен правильно. Если же конфликт на самом деле есть (возможно два разработчика добавили новый ресурс или объект в разных ветках), сохраненный в памяти объект будет вставлен с новым ID. Так же в этом случае для него будет запущена команда Gitify extract.
        Ничего не понятно. С честь чего «объект временно сохраняется в памяти». Мм… это понял — билд же делается. Схема работы: с базы локального сайта делается extract в файлы Gitify, файлы Gitify синхронизируются с репозиторием git, другой разработчик синхронизирует репозиторий git со своими файлами Gitify и делает билд данных в свою копию сайта.
        Интересно :). Только как быть с рабочим сайтом, который находиться где-то на хостинге где есть только apache и ftp. Как его обновлять?
        сохраненный в памяти объект будет вставлен с новым ID. Так же в этом случае для него будет запущена команда Gitify extract.
        Не слишком приятно :(. В коде может ссылка на id ресурса. При изменении его id нужно править код.
          Иван Климчук
          20 декабря 2015, 21:16
          +2
          Я не в коем случае не отговариваю вас, любые начинания — это только в плюс и уверен, что ваше решение будет лучше. Хотелось бы на это надеятся. Но за почти 6 лет работы с MODX я уже набил шишек на теме синхронизации копий сайтов на MODX и знаю в этом толк, как говорится.

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

          Ирония по поводу умной фразы в описании проекта меня изумляет, потому что, прежде чем давать оценки, стоит хотя бы попробовать инструмент. Gitify уже 2 года как успешно справляется с этой задачей. Его использует команда modmore, все мои сайты тоже синхронизируются через него. Так что да, я уверен в его возможностях, а чего не хватает – дописываю. Ну а уповать на то, что в гугле этот инструмент не ищется по запросу на русском языке, когда основной разработчик пользуется английским, ну я даже не знаю. Вроде и не глупо, но не дальновидно.

          Разруливание конфликтов ID тема сложная и объяснить одним абзацем действительно проблематично, тем не менее на сейчас это наверное пожалуй самый адекватный алгоритм из существующих. Но и он не идеален, я без проблем это признаю.

          Воспринимайте мой ответ, как конструктивную критику, а не как нападки. Я очень хотел бы видеть удобный инструмент синхронизации между сайтами, но уже на начальном этапе вижу проблемы в вашем решении. Хорошо, если получится их решить сейчас, в начале пути, когда есть еще время переделать.
            Александр
            20 декабря 2015, 23:08
            0
            Простите за язвительность. Раздражен был тем, что веллосипед делал. Проблема в том, что прежде чем писать, я потратил довольно много времени на поиск нужного компонента. И ничего не нашел… Искал на на русском. Английский меня раздражает. Вашу документацию сложно найти. Для новичка. До запроса modx двунаправленную синхронизацию данных еще додуматься надо. Конечно
            Цель Gitify — обеспечить двунаправленную синхронизацию данных, обычно хранящихся в базе данных MODX, что позволит версионировать код через Git.
            полное описание для посвященного в идеалогию git. Но если развернуть это предложение на пару абзацев, в поиске найти Gitify будет гораздо проще.

            Для текущих задач, ChangePack мне подходит. Работает как и задумывался. Хотя интересно сделать лучше. Можно выделять на каждую копию сайта пул id и после создания ресурса перезаписывать его id разрешенным id. Возможно подойдет для 2-5 разработчиков. Но это уже без «версионировать код через Git». Неясно будет ли компонент полезным. И захотят ли его, например, купить :). Сейчас буду текущим проектом заниматься. Дорабатывать нет времени.
              Иван Климчук
              20 декабря 2015, 23:13
              +1
              Работа с ID на самом деле очень большая проблема. И для контента я gitify не использую, как и другие средства, так как содержимое как правило генерируется или пользователями или менеджерами сайта, поэтому content у меня просто исключен из выгрузки/загрузки, но для кода конфликты по ID не столь существенны и автоматическое разруливание вполне справляется.

              По документации да, она не идеальна, над ней стоит поработать, я этим занимаюсь, но не всегда хватает времени сделать ее толково.
    Abu
    Abu
    19 декабря 2015, 14:30
    2
    0
    Пользуюсь для таких случаев возможностями ssh
    mysql
    mysqldump --opt -C -uusername -ppass  mysqldatabase | ssh -C -i  /keys/.ssh/key.pem sshuser@192.168.0.1 mysql -C -uusername -ppassword  mysqldatabase
    файлы
    sudo rsync -avz --delete -progress -e "ssh -i /keys/.ssh/key.pem" --rsync-path="sudo rsync" /var/www/username/site.com/ sshuser@192.168.1.0:/var/www/username/site.com/
    Таким же образом можно затягивать обновления с рабочего сервера. Генерация баш скриптов при создании сайта упрощает и написание этих строчек.

    Компоненту, конечно, плюс. Управление с админки и дополнительные фичи с бекапом и выбором данных для синхронизации, то что нужно.
      ck
      ck
      19 декабря 2015, 23:29
      +1
      На прошедшей встрече в Минске Иван Климчук рассказывал про компонент Gitify. Он сохраняет все изменения элементов разработчика в файлы. Далее эти изменения можно перебрасывать на любой проект через Git или с помощью собственных команд.
      Работает через консоль.
        Александр Котлов
        20 декабря 2015, 01:03
        0
        Не всех элементов, а только тех что он умеет и понимает, например настройки ClientConfig он не сохраняет, что довольно забавно учитывая что у обоих дополнений 1 разработчик (точнее 1 основной разработчик).
          Иван Климчук
          20 декабря 2015, 14:54
          0
          Вообще-то сохраняет :-P
          clientconfig_groups:
                  class: cgGroup
                  primary: label
                  package: clientconfig
              clientconfig_settings:
                  class: cgSetting
                  primary: key
          Он умеет любую сущность, которая описана в schema дампить, нужно только package указать. C miniShop2 работает идеально. :)
            Александр Котлов
            20 декабря 2015, 15:04
            +1
            Я специально написал чтобы ты раскололся))) Быстрее статью пиши)
              Роман Садоян
              21 декабря 2015, 01:47
              0
              Анонс был, статьи нет, мы ждем!
                Иван Климчук
                21 декабря 2015, 01:49
                +2
                На неделе опубликую, нужно было отдохнуть после митапа, все неделю в напряжении был. :)
              Алексей Федоров
              24 декабря 2015, 12:28
              0
              Вот, кстати, вопрос. По ClientConfig документация на русском с примерами где-то существует?

              Почитал оригинальную, вроде понятно, но не совсем. «Ключ» присваивается в качестве имени плейсхолдера или наоборот нужно взять существующий плейсхолдер и сформировать из него ключ. Опять же на инглише пример для селектора «да-нет» написан. А вот пример для смены фона шапки как сделать не разобрался(( не настолько я в этом деле опытен. Стоит ли вообще с ним заморачиваться без знания php? Потому как добавить возможность для группы пользователей менять шапку в своем «подотчетном» разделе — штука полезная и нужная. Но ее можно и через добавление TV сделать. Другое дело, что собрать все такие вот настройки в одну кучу — это здорово, но с моим уровнем знаний без примеров разобраться нереально(

              Поэтому очень интересует существует такая информация в сети вообще или нет?
                Воеводский Михаил
                24 декабря 2015, 12:42
                +1
                Добавленные через CilentConfig записи почти ничем не отличаются от обычных системных настроек.
                В шаблонах и чанках вызываются так: [[+key]]
                В php вызывается так: $modx->getOption('key');
              Александр
              20 декабря 2015, 03:36
              0
              Интересно :). Знал бы, не разрабатывал свой веллосипед :). Но свой велосипед пока удобнее, потом посмотрим…
              Воеводский Михаил
              21 декабря 2015, 15:20
              0
              На прошедшей конференции я рассказывал о синхронизации множества установленных копий. Как Иван правильно отмечает, с ID ситуация не слишком однозначная. К тому же, когда появляется второй (и не только) разработчик, становится сложнее управлять всеми изменениями.

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

              Заодно уж: Иван, расскажи, пжл, насколько Gitify подходит для поддержки одновременно нескольких рабочих серверов?
                Иван Климчук
                21 декабря 2015, 16:13
                0
                Имеется ввиду, когда сайт один, но разнесен на несколько серверов физически? Ибо gitify — это все же инструментр скорее для разработчик/разработчика, нежели для деплоя проектов. Он может, но это побочный эффект так сказать :) Но в теории да, может. Так как код в репозитории будет один на все инстансы.
                  Воеводский Михаил
                  21 декабря 2015, 16:27
                  0
                  Этот момент тоже стоит проверить и осветить, если Gitify корректно сумеет поддерживать в актуальном состоянии несколько рабочих копий. В теории сложностей не должно быть, это факт. Как на практике — вопрос :)
                    Fi1osof
                    21 декабря 2015, 16:50
                    0
                    В теории сложностей может быть ох как много, вот это факт. Простой пример: работают два разраба. Один ТВшку новую создал (у него на сайте id 5), и другой ТВшку новую создал (и у этого id 5). На главный сайт они создадутся как новые ТВшки с новыми id-шниками (5 и 6 (ибо id-шники не сохраняются при переносе как раз во избежание конфликтов id)). Так вот, и тот и другой прописал у себя в кодах $resource->getTVValue(5). Или $c->innerJoin('modTemplateVarResource', 'tv', 'tv.id = 5 AND tv.resourceid = modResource.id'); Что мы на выходе будем иметь? Верно. Проблемы. А оперировать в запросах не айдишниками — это часто совсем не круто.
                      Воеводский Михаил
                      21 декабря 2015, 17:01
                      0
                      Верно, это далеко не единственная частность.
                      Таких подводных камней бесчисленное множество. По этой причине, создавая инструмент переноса данных, необходимо сразу определиться с некоторыми условностями. Например, запретить изменение username пользователям, не переименовывать TV после отправки по другим сайтам и тд.

                      Ресурсы можно тоже легко и успешно переносить между сайтами, изменять их содержимое, здесь вариантов 2:
                      1) В самом ресурсе определить поле, которое не изменяется ни при каких условиях
                      2) Создать отдельную таблицу, в которой будет сохраняться соответствие ресурса и дополнительного служебного кода этого ресурса. Кстати, мой синхронизатор стоит дополнить вторым механизмом, получится более красивая и удобная вещь.
                        Fi1osof
                        21 декабря 2015, 17:32
                        0
                        Здесь вряд ли возможен идеальный вариант. И я по-другому делаю. У меня же смарти, то есть практически все на файлах. Тут у меня нет проблем с синхронизацией (просто гитом). А вот если надо MODX-элементы добавить, то тогда я создаю новую версию скина сайта боевого, плагином переключаюсь на новую версию и веду работы на нем. Обычные пользователи видят старую версию скина и новые ТВшки их никак не касаются. А я работаю на новом скине. Когда все сделано, я переключаю скин для всех. После этого заливаю новую базу на дев-сайт (чтобы была точная копия).
                          Воеводский Михаил
                          21 декабря 2015, 17:56
                          0
                          Тоже очень хороший вариант.
                          Что касается идеального варианта, единственный способ сделать универсально — задать какие-то минимальные рамки, соблюдения которых требовать от всех разработчиков, которые выберут твой инструмент для работы. А дальше решение уже за ними — если соблюдают, то все хорошо и корректно переносится. Если нарушают требования, то иногда получают непредсказуемый вариант.

                          При этом, синхронизатор должен иметь несколько режимов работы. Как минимум:
                          1) Управление копиями через мастер-сервер
                          2) Выгрузка обновлений с тестового сервера на рабочий (-е).

                          Если же мы говорим о работе и изменениях непосредственно на рабочем, например, как в твоем случае, то здесь вообще синхронизатор не нужен. Достаточно простого протоколирования изменений.
                Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
                24