Контроль версий и деплой при разработке сайтов на MODX



Проблема контроля версий, деплоя, возможности командной работы издавна занимают умы разработчиков.

Анализ существующих решений


Вот, например, Николай Ланец предлагает отказаться от Git и хранить версии в виде пакетов, благо MODX умеет их нормально собирать, устанавливать, откатывать до предыдущих версий… Подход интересный, но для понимания нужно обладать достаточно высокой квалификацией.

Василий Наумкин смотрит в эту же сторону.

Иван Климчук предлагает пользоваться телепортом, для которого все-таки нужен сервер, хотя бы для того, чтобы установить сам Teleport. Кроме того проблемы с контролем версий не решает, насколько я понял. Позволяет только упростить деплой. Ну и эти JSON-шаблоны профилей меня немного пугают.

Вадим Хомчик на той же конференции показал, как происходит разработка сайтов в WEBTECHNICO. Все хорошо, но YAML-метаданные… Да, это вынужденное зло… Но для проектов по-проще и для программистов по-младше вряд ли будет интересно.

О методике


Я не претендую на истину, даже хоть на какое-то новшество. Просто хочется сделать пошаговую инструкцию — самому себе в голове разложить методику по полочкам.

Мне очень приглянулось дополнение, которое мельком упомянул Иван. Он указал на все его недостатки, которые мне, однако, показались не очень существенными для большинства моих проектов. Это чудное дополнение — SE Manager от LOVATA Group, LLC (насколько я знаю, сам Иван его и разработал)

Схема разработки


Cхема видится мне так:



Мы работаем с DEV-сайтом, все изменения идут прямиком на Github (Bitbucket или др. — не принципиально), а уже с него на Production-сайт.

Переносить таким образом мы сможем только элементы (шаблоны, чанки, сниппеты, плагины) и файлы (css, js, картинки, быть может, видео или аудио — все, что относится к конкретному сайту).

Системные настройки, установленные дополнения, созданные разделы придется дублировать вручную. Кстати, документы все синхронизировать не надо — пусть на Production-сайте больше статей. На то он и Production ))

Видео-инструкция


Саму процесс проще показать на видео, чем описывать. Видео получилось длинное, звукового сопровождения нет, но надеюсь, все скучные моменты я вырезал.

Общее содержание ролика:

  • Создание DEV-сайта
  • Установка нужных дополнений
  • Создание папки template, в которой и будут лежать все синхронизируемые файлы
  • Установка SE Manager и включение автоматического создания элементов из файлов
  • Создание нового проекта в NetBeans (подключение по FTP)
  • Создание папок для чанков, сниппетов, шаблонов и плагинов
  • Создание шаблона в виде файла
  • Проверка корректности создания шаблона шаблон
  • Внедрение в шаблон верстки
  • Разбиение шаблона на чанки (обратите внимание, чанки придется вызывать некешированными)
  • Создание тестовых статей
  • Вывод статей на страницу
  • Создание репозитория Git (нужен доступ по SSH)
  • Создание Production-сайта как дубля DEV (перенос сайта)
  • Создание ветки dev
  • Внесение изменений в ветке dev
  • Переключение между ветками
  • Merge ветки dev в master
  • Деплой на Production-сайт через Github
  • Создание меню на DEV-сайте, первая ошибка, которая не повлияла на Production
  • Исправление ошибки, тестирование на DEV-сайте и еще один деплой на Production
Удачного просмотра.



Подробная версия



Илья Уткин
29 января 2015, 23:04
modx.pro
16
6 346
+4
Поблагодарить автора Отправить деньги

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

Alexander V
30 января 2015, 02:25
+1
И снова немое кино. Многие порадуются за вас, что вы так умеете) На минском видео была эта тема. Но их ролики досмотреть не осилил. Со звуком творилось что-то невероятное.
    Михаил
    30 января 2015, 05:56
    0
    Можем озвучить )
    Иван Климчук
    30 января 2015, 08:46
    0
    А что именно не так со звуком? К сожалению, микрофоны-петлички использовать нельзя было, иначе терялась связь с залом, а нанимать профи для записи видео выходило за рамки бюджета бесплатного митапа. Но что мог, то вытянул в видео-редакторе.
      Alexander V
      30 января 2015, 11:04
      0
      Да, как раз микрофоны бы не помешали. Тяжело смотреть длинные записи, когда приходится прислушиваться, отвлекает от темы.
Василий Наумкин
30 января 2015, 07:15
+1
Взял на себя смелость немного подкорректировать пост. Теперь видео нормально отображается, и вместо 5 больших картинок стало 2.

Надеюсь, никто не против.
Иван Климчук
30 января 2015, 08:48
0
По теме, то создавать папки вручную не нужно, так как в плагине есть функция, которая согласно настройкам создает все необходимые папки по указанным путям, если их нет.
Ганин Роман
30 января 2015, 10:54
0
А как на счёт CaST? Это обёртка над Гитом для телепортации MODX, позволяющая выборочно «делать снимки» пользователей, чанков, отдельных ресурсов, системных настроек или всего сайта в целом. И также выборочно «разворачивать».
    Ганин Роман
    30 января 2015, 10:56
    0
    Но она тоже консольная и требует права на запуск сервиса php… Но вас это ведь не смущает, правда? =)
      Илья Уткин
      30 января 2015, 10:59
      0
      Смущает — хочется, чтобы была возможность размещать сайты клиентов на обычных shared-хостингах
    Илья Уткин
    30 января 2015, 10:59
    0
    Очень похоже, что CaST — это ранняя версия телепорта) Я уверен, что способов есть много (у каждого свой) и в будущем появится еще больше. Хочется, чтобы каждый поделился своей методикой.
      Ганин Роман
      30 января 2015, 11:03
      0
      Да, так и есть. Есть ещё Vapor, кстати.
Иван Брежнев
30 января 2015, 11:55
0
Системные настройки, установленные дополнения, созданные разделы придется дублировать вручную. Кстати, документы все синхронизировать не надо — пусть на Production-сайте больше статей. На то он и Production ))

Для этого разумно было бы создать компонент скажем Миграции (как во фреймах) и все изменения в системных настройках, созданных чанках и т.п. (конечно которые касаются непосредственно сайта, а не конкретного пакета) оформлять в виде миграций. Например добавил я системную настройку `Some setting` захожу в компонент Миграции, нажимаю создать миграция, описываю там весь процесс создания системной настройки, создается файл с опред. именем, этот файл отправляется на гит, другой разработчик обновляется с гита, заходит в компонент Миграции и нажимает «Накатить миграции» (Мигрировать, Выполнить миграции по вкусу) и вуаля, имеем в базе все изменения внесенные другим разработчиком.

Конечно для миграций создается таблица в базе с одноименным именем, ранее выполненные миграции пишутся в неё, и при след. миграции не обновляются.

Так же в миграции мы описывает и откат до пред. состояния. Что вполне логично.
    Иван Климчук
    06 марта 2015, 11:38
    0
    такая штука у команды MODX есть, в Teleport для этого даже шаблон предусмотрен, но они ее пока нигде не публиковали, а Джейсон как-то говорил, что скорее всего на платной основе будут распространять. Но прошло уже пару месяцев и пока не слышно ничего вообще.
Илья Уткин
30 января 2015, 15:00
0
Вырезал из видео много лишнего, сократил до 11 минут.
Воеводский Михаил
31 января 2015, 12:43
0
Обеспечиваю поддержку в актуальном состоянии 11 одинаковых копий MODX с одинаковым набором собственных компонентов — тоже считаю оптимальным вариантом использование пакетов. Удобство заключается в простом контроле установленных версий и легком обновлении или, наоборот, откате до нужной версии.

Вкупе с приватным репозитарием, не вижу смысла изменять вшитый в MODX грамотный метод работы с компонентами.

Но, возможно, это имеет смысл только при большом количестве однотипных копий. Если же у Вас один сервер для разработки и только один публичный, пакеты могут оказаться слишком громоздкими.
Андрей Иванов
28 февраля 2015, 12:48
0
Начал пробовать тему. А как быть с TV-параметрами?
    Илья Уткин
    28 февраля 2015, 15:30
    0
    Не знаю… Я их особо не использую. Вот что там можно хранить такого?
      Андрей Иванов
      28 февраля 2015, 21:28
      0
      Я уже не в первый раз слышу, что TV-параметры можно не использовать. А как это реализовать не подскажете? Изображения, MIGX...? Это не оффтопик, в контексте все)
        Илья Уткин
        02 марта 2015, 11:13
        0
        Я не говорю, что не надо использовать. Но сколько нужно ТВ на сайте? 2? 3? Их можно вручную создать на обоих серверах. А значения переносить не надо — контент вполне может быть разным.
          Андрей Иванов
          02 марта 2015, 11:58
          0
          Ну а как можно, к примеру, поступить с длинным перечнем характеристик, скажем, ТТХ?
Максим Франц
22 августа 2015, 19:17
0
Скажите,
как это «Разбиение шаблона на чанки (обратите внимание, чанки придется вызывать некешированными)»
повлияет на скорость работы сайта?
    Илья Уткин
    22 августа 2015, 19:25
    0
    Не знаю. Не тестировал.
      Максим Франц
      22 августа 2015, 19:56
      0
      Можно попросить Вас подробней описать «недостатки, которые мне, однако, показались не очень существенными»?

      Не знаю должно ли так быть, но после установки SEManager у меня cлетел Ace, переустановка помогла.
      И в настройках SEManager не хватает кнопки «вернуть все как было» :)
        Илья Уткин
        24 августа 2015, 10:51
        0
        Минусы его в том, что он сохраняет в файлах только элементы. Ни настройки системы, ни ТВ-параметры, ни наборы компонентов — ничего не сохраняется в папке. Это все нужно руками дублировать. Но я настройки системы меняю редко, компонент не сложно два раза поставить, так что для меня эти минусы незначительны.

        А вот автоматическое создание, например, чанков из файлов — очень интересный плюс
Андрей
04 сентября 2017, 10:42
0
Илья, появились ли какие-то изменения в алгоритме за прошедшее время? Было бы интересно как вы работаете сейчас?
    Илья Уткин
    04 сентября 2017, 11:18
    0
    Ну сейчас SEManager особо не нужен — Fenom позволяет работать с файловыми элементами. А в остальном изменений никаких не было)
      Андрей
      05 сентября 2017, 19:07
      0
      Спасибо. Илья, подскажите такой момент, не совсем понял из видео: сам проект у нас в IDE а далее вы создаете репозиторий на Github и в консоли перехожу в папку проекта. Далее набираю команду
      git init
      И мне вылезает ошибка
      bash: git: command not found
      Скажите, как ее побороть?
        Павел Гвоздь
        05 сентября 2017, 22:37
        +1
        Удивительно! Нынче самостоятельно искать решение в Интернетах не модно, видимо…
          Андрей
          05 сентября 2017, 23:48
          0
          Не) Я искал… честно)) Правильно ли я понимаю, что мне нужен SSH ключ?
Andrey
17 марта 2018, 21:44
0
Доброго дня! Проблема, куда копать?

Как с сервера dev перекинуть на обычный сервер папки, минуя локальный хостинг?
Что имеется ввиду, если у нас версия разработки и публичная версия находятся на сервере. Где информацию найти как настроить?

Нашел как лить на локальный сервер, и с него уже лить на гит, получается литье в три потока, сначала льем на сервер разработки, потом с него, потом на гит и потом на сайт…
Может я чего не понял, видео же показывает что льется сразу с сервера на гит и на сервер
    Илья Уткин
    19 марта 2018, 08:47
    0
    На обычный сервер надо заливать изменения через SSH командой
    git pull
    Тогда сервер сам обратится на github.com, и скачает актуальные файлы.
      Andrey
      19 марта 2018, 21:05
      0
      Илья это понятно, спасибо
      git pull

      Непонятно вот что, мы версию разработчика создаем не локально, а на хостинге
      А гиту нужно сначала скачать файлы с локального сервера и потом залить на гит и уже после обновить версию оригинальную… То есть
      Хостинг Dev -> Локальный сервер -> Гит -> Оригинальная версия
      А сам гит работает так
      Локальный сервер -> Гит -> Оригинальная версия

      Как залить с хостинга на гит напрямую? Возможно это php storm делает, ели его настроить? Сразу Pull делать?
      Установлен Notepad++
Andrey
14 апреля 2018, 21:16
0
Вроде разобрался… Назрел вопрос в видео обращение происходит к двум серверам один dev, а другой реальный.

Через терминал обращение идет и к dev и к реальному. У меня на Гит создана только dev версия проекта… Собственно должна быть еще и реальная??
Не понятен процесс взаимодействия с Гитом.

Повторю: Создаем на GIT два проекта — один dev, другой рабочий.
1. Начинаем работать на dev. создаем всю необходимую структуру устанавливаем все сниппеты и плагины.
2. Копируем и базу данных и весь проект, через FTP и объединяем базу данных — она одна на два проекта.
3. Дальше изменения вносим на dev и заливаем их на GIT
4. Далее в терминале меняем проект на рабочую версию и применяем изменения

Правильно ли я понял? Важный момент, что на GIThub «2 проекта»
    Илья Уткин
    16 апреля 2018, 11:56
    0
    Не совсем. Проект на GitHub только один. Тут надо понимать отличие между git и GitHub — первое это просто программа на сервере, второе — это сайт и своеобразный хостинг файлов. У GitHub есть аналоги — Bitbucket, например. Или ты можешь даже сам сделать такой удалённый репозиторий. А можно работать и без него.

    На видео схема такая. Есть 3 репозитория. Один внутри программы git на Dev-сервере, второй внутри программы git на Production-сервере и третий — главный, на сервере GitHub. Все эти три репозитория связаны. Но можно сделать схему и без GitHub вообще. Можно просто связать два репозитория друг с другом напрямую (только это сложнее в настройке)
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
38