Контроль версий и деплой при разработке сайтов на 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
Подробная версия
Комментарии: 38
И снова немое кино. Многие порадуются за вас, что вы так умеете) На минском видео была эта тема. Но их ролики досмотреть не осилил. Со звуком творилось что-то невероятное.
Можем озвучить )
А что именно не так со звуком? К сожалению, микрофоны-петлички использовать нельзя было, иначе терялась связь с залом, а нанимать профи для записи видео выходило за рамки бюджета бесплатного митапа. Но что мог, то вытянул в видео-редакторе.
Да, как раз микрофоны бы не помешали. Тяжело смотреть длинные записи, когда приходится прислушиваться, отвлекает от темы.
Взял на себя смелость немного подкорректировать пост. Теперь видео нормально отображается, и вместо 5 больших картинок стало 2.
Надеюсь, никто не против.
Надеюсь, никто не против.
По теме, то создавать папки вручную не нужно, так как в плагине есть функция, которая согласно настройкам создает все необходимые папки по указанным путям, если их нет.
А как на счёт CaST? Это обёртка над Гитом для телепортации MODX, позволяющая выборочно «делать снимки» пользователей, чанков, отдельных ресурсов, системных настроек или всего сайта в целом. И также выборочно «разворачивать».
Но она тоже консольная и требует права на запуск сервиса php… Но вас это ведь не смущает, правда? =)
Смущает — хочется, чтобы была возможность размещать сайты клиентов на обычных shared-хостингах
Очень похоже, что CaST — это ранняя версия телепорта) Я уверен, что способов есть много (у каждого свой) и в будущем появится еще больше. Хочется, чтобы каждый поделился своей методикой.
Да, так и есть. Есть ещё Vapor, кстати.
Системные настройки, установленные дополнения, созданные разделы придется дублировать вручную. Кстати, документы все синхронизировать не надо — пусть на Production-сайте больше статей. На то он и Production ))
Для этого разумно было бы создать компонент скажем Миграции (как во фреймах) и все изменения в системных настройках, созданных чанках и т.п. (конечно которые касаются непосредственно сайта, а не конкретного пакета) оформлять в виде миграций. Например добавил я системную настройку `Some setting` захожу в компонент Миграции, нажимаю создать миграция, описываю там весь процесс создания системной настройки, создается файл с опред. именем, этот файл отправляется на гит, другой разработчик обновляется с гита, заходит в компонент Миграции и нажимает «Накатить миграции» (Мигрировать, Выполнить миграции по вкусу) и вуаля, имеем в базе все изменения внесенные другим разработчиком.
Конечно для миграций создается таблица в базе с одноименным именем, ранее выполненные миграции пишутся в неё, и при след. миграции не обновляются.
Так же в миграции мы описывает и откат до пред. состояния. Что вполне логично.
такая штука у команды MODX есть, в Teleport для этого даже шаблон предусмотрен, но они ее пока нигде не публиковали, а Джейсон как-то говорил, что скорее всего на платной основе будут распространять. Но прошло уже пару месяцев и пока не слышно ничего вообще.
Вырезал из видео много лишнего, сократил до 11 минут.
Обеспечиваю поддержку в актуальном состоянии 11 одинаковых копий MODX с одинаковым набором собственных компонентов — тоже считаю оптимальным вариантом использование пакетов. Удобство заключается в простом контроле установленных версий и легком обновлении или, наоборот, откате до нужной версии.
Вкупе с приватным репозитарием, не вижу смысла изменять вшитый в MODX грамотный метод работы с компонентами.
Но, возможно, это имеет смысл только при большом количестве однотипных копий. Если же у Вас один сервер для разработки и только один публичный, пакеты могут оказаться слишком громоздкими.
Вкупе с приватным репозитарием, не вижу смысла изменять вшитый в MODX грамотный метод работы с компонентами.
Но, возможно, это имеет смысл только при большом количестве однотипных копий. Если же у Вас один сервер для разработки и только один публичный, пакеты могут оказаться слишком громоздкими.
Начал пробовать тему. А как быть с TV-параметрами?
Не знаю… Я их особо не использую. Вот что там можно хранить такого?
Я уже не в первый раз слышу, что TV-параметры можно не использовать. А как это реализовать не подскажете? Изображения, MIGX...? Это не оффтопик, в контексте все)
Я не говорю, что не надо использовать. Но сколько нужно ТВ на сайте? 2? 3? Их можно вручную создать на обоих серверах. А значения переносить не надо — контент вполне может быть разным.
Ну а как можно, к примеру, поступить с длинным перечнем характеристик, скажем, ТТХ?
Скажите,
как это «Разбиение шаблона на чанки (обратите внимание, чанки придется вызывать некешированными)»
повлияет на скорость работы сайта?
как это «Разбиение шаблона на чанки (обратите внимание, чанки придется вызывать некешированными)»
повлияет на скорость работы сайта?
Не знаю. Не тестировал.
Можно попросить Вас подробней описать «недостатки, которые мне, однако, показались не очень существенными»?
Не знаю должно ли так быть, но после установки SEManager у меня cлетел Ace, переустановка помогла.
И в настройках SEManager не хватает кнопки «вернуть все как было» :)
Не знаю должно ли так быть, но после установки SEManager у меня cлетел Ace, переустановка помогла.
И в настройках SEManager не хватает кнопки «вернуть все как было» :)
Минусы его в том, что он сохраняет в файлах только элементы. Ни настройки системы, ни ТВ-параметры, ни наборы компонентов — ничего не сохраняется в папке. Это все нужно руками дублировать. Но я настройки системы меняю редко, компонент не сложно два раза поставить, так что для меня эти минусы незначительны.
А вот автоматическое создание, например, чанков из файлов — очень интересный плюс
А вот автоматическое создание, например, чанков из файлов — очень интересный плюс
Илья, появились ли какие-то изменения в алгоритме за прошедшее время? Было бы интересно как вы работаете сейчас?
Ну сейчас SEManager особо не нужен — Fenom позволяет работать с файловыми элементами. А в остальном изменений никаких не было)
Спасибо. Илья, подскажите такой момент, не совсем понял из видео: сам проект у нас в IDE а далее вы создаете репозиторий на Github и в консоли перехожу в папку проекта. Далее набираю команду
git initИ мне вылезает ошибка
bash: git: command not foundСкажите, как ее побороть?
Удивительно! Нынче самостоятельно искать решение в Интернетах не модно, видимо…
Не) Я искал… честно)) Правильно ли я понимаю, что мне нужен SSH ключ?
Нет.
Аааа, получается у меня Git не установлен на сервере?
Вот теперь верно.
Спасибо)) все починил
Доброго дня! Проблема, куда копать?
Как с сервера dev перекинуть на обычный сервер папки, минуя локальный хостинг?
Что имеется ввиду, если у нас версия разработки и публичная версия находятся на сервере. Где информацию найти как настроить?
Нашел как лить на локальный сервер, и с него уже лить на гит, получается литье в три потока, сначала льем на сервер разработки, потом с него, потом на гит и потом на сайт…
Может я чего не понял, видео же показывает что льется сразу с сервера на гит и на сервер
Как с сервера dev перекинуть на обычный сервер папки, минуя локальный хостинг?
Что имеется ввиду, если у нас версия разработки и публичная версия находятся на сервере. Где информацию найти как настроить?
Нашел как лить на локальный сервер, и с него уже лить на гит, получается литье в три потока, сначала льем на сервер разработки, потом с него, потом на гит и потом на сайт…
Может я чего не понял, видео же показывает что льется сразу с сервера на гит и на сервер
На обычный сервер надо заливать изменения через SSH командой
git pull
Тогда сервер сам обратится на github.com, и скачает актуальные файлы.
Илья это понятно, спасибо
Непонятно вот что, мы версию разработчика создаем не локально, а на хостинге…
А гиту нужно сначала скачать файлы с локального сервера и потом залить на гит и уже после обновить версию оригинальную… То есть
Хостинг Dev -> Локальный сервер -> Гит -> Оригинальная версия
А сам гит работает так
Локальный сервер -> Гит -> Оригинальная версия
Как залить с хостинга на гит напрямую? Возможно это php storm делает, ели его настроить? Сразу Pull делать?
Установлен Notepad++
git pull
Непонятно вот что, мы версию разработчика создаем не локально, а на хостинге…
А гиту нужно сначала скачать файлы с локального сервера и потом залить на гит и уже после обновить версию оригинальную… То есть
Хостинг Dev -> Локальный сервер -> Гит -> Оригинальная версия
А сам гит работает так
Локальный сервер -> Гит -> Оригинальная версия
Как залить с хостинга на гит напрямую? Возможно это php storm делает, ели его настроить? Сразу Pull делать?
Установлен Notepad++
Вроде разобрался… Назрел вопрос в видео обращение происходит к двум серверам один dev, а другой реальный.
Через терминал обращение идет и к dev и к реальному. У меня на Гит создана только dev версия проекта… Собственно должна быть еще и реальная??
Не понятен процесс взаимодействия с Гитом.
Повторю: Создаем на GIT два проекта — один dev, другой рабочий.
1. Начинаем работать на dev. создаем всю необходимую структуру устанавливаем все сниппеты и плагины.
2. Копируем и базу данных и весь проект, через FTP и объединяем базу данных — она одна на два проекта.
3. Дальше изменения вносим на dev и заливаем их на GIT
4. Далее в терминале меняем проект на рабочую версию и применяем изменения
Правильно ли я понял? Важный момент, что на GIThub «2 проекта»
Через терминал обращение идет и к dev и к реальному. У меня на Гит создана только dev версия проекта… Собственно должна быть еще и реальная??
Не понятен процесс взаимодействия с Гитом.
Повторю: Создаем на GIT два проекта — один dev, другой рабочий.
1. Начинаем работать на dev. создаем всю необходимую структуру устанавливаем все сниппеты и плагины.
2. Копируем и базу данных и весь проект, через FTP и объединяем базу данных — она одна на два проекта.
3. Дальше изменения вносим на dev и заливаем их на GIT
4. Далее в терминале меняем проект на рабочую версию и применяем изменения
Правильно ли я понял? Важный момент, что на GIThub «2 проекта»
Не совсем. Проект на GitHub только один. Тут надо понимать отличие между git и GitHub — первое это просто программа на сервере, второе — это сайт и своеобразный хостинг файлов. У GitHub есть аналоги — Bitbucket, например. Или ты можешь даже сам сделать такой удалённый репозиторий. А можно работать и без него.
На видео схема такая. Есть 3 репозитория. Один внутри программы git на Dev-сервере, второй внутри программы git на Production-сервере и третий — главный, на сервере GitHub. Все эти три репозитория связаны. Но можно сделать схему и без GitHub вообще. Можно просто связать два репозитория друг с другом напрямую (только это сложнее в настройке)
На видео схема такая. Есть 3 репозитория. Один внутри программы git на Dev-сервере, второй внутри программы git на Production-сервере и третий — главный, на сервере GitHub. Все эти три репозитория связаны. Но можно сделать схему и без GitHub вообще. Можно просто связать два репозитория друг с другом напрямую (только это сложнее в настройке)
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.