Контроль версий и деплой при разработке сайтов на 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
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Надеюсь, никто не против.
Для этого разумно было бы создать компонент скажем Миграции (как во фреймах) и все изменения в системных настройках, созданных чанках и т.п. (конечно которые касаются непосредственно сайта, а не конкретного пакета) оформлять в виде миграций. Например добавил я системную настройку `Some setting` захожу в компонент Миграции, нажимаю создать миграция, описываю там весь процесс создания системной настройки, создается файл с опред. именем, этот файл отправляется на гит, другой разработчик обновляется с гита, заходит в компонент Миграции и нажимает «Накатить миграции» (Мигрировать, Выполнить миграции по вкусу) и вуаля, имеем в базе все изменения внесенные другим разработчиком.
Конечно для миграций создается таблица в базе с одноименным именем, ранее выполненные миграции пишутся в неё, и при след. миграции не обновляются.
Так же в миграции мы описывает и откат до пред. состояния. Что вполне логично.
Вкупе с приватным репозитарием, не вижу смысла изменять вшитый в MODX грамотный метод работы с компонентами.
Но, возможно, это имеет смысл только при большом количестве однотипных копий. Если же у Вас один сервер для разработки и только один публичный, пакеты могут оказаться слишком громоздкими.
как это «Разбиение шаблона на чанки (обратите внимание, чанки придется вызывать некешированными)»
повлияет на скорость работы сайта?
Не знаю должно ли так быть, но после установки SEManager у меня cлетел Ace, переустановка помогла.
И в настройках SEManager не хватает кнопки «вернуть все как было» :)
А вот автоматическое создание, например, чанков из файлов — очень интересный плюс
И мне вылезает ошибка
Скажите, как ее побороть?
Как с сервера dev перекинуть на обычный сервер папки, минуя локальный хостинг?
Что имеется ввиду, если у нас версия разработки и публичная версия находятся на сервере. Где информацию найти как настроить?
Нашел как лить на локальный сервер, и с него уже лить на гит, получается литье в три потока, сначала льем на сервер разработки, потом с него, потом на гит и потом на сайт…
Может я чего не понял, видео же показывает что льется сразу с сервера на гит и на сервер
Тогда сервер сам обратится на github.com, и скачает актуальные файлы.
Непонятно вот что, мы версию разработчика создаем не локально, а на хостинге…
А гиту нужно сначала скачать файлы с локального сервера и потом залить на гит и уже после обновить версию оригинальную… То есть
Хостинг Dev -> Локальный сервер -> Гит -> Оригинальная версия
А сам гит работает так
Локальный сервер -> Гит -> Оригинальная версия
Как залить с хостинга на гит напрямую? Возможно это php storm делает, ели его настроить? Сразу Pull делать?
Установлен Notepad++
Через терминал обращение идет и к dev и к реальному. У меня на Гит создана только dev версия проекта… Собственно должна быть еще и реальная??
Не понятен процесс взаимодействия с Гитом.
Повторю: Создаем на GIT два проекта — один dev, другой рабочий.
1. Начинаем работать на dev. создаем всю необходимую структуру устанавливаем все сниппеты и плагины.
2. Копируем и базу данных и весь проект, через FTP и объединяем базу данных — она одна на два проекта.
3. Дальше изменения вносим на dev и заливаем их на GIT
4. Далее в терминале меняем проект на рабочую версию и применяем изменения
Правильно ли я понял? Важный момент, что на GIThub «2 проекта»
На видео схема такая. Есть 3 репозитория. Один внутри программы git на Dev-сервере, второй внутри программы git на Production-сервере и третий — главный, на сервере GitHub. Все эти три репозитория связаны. Но можно сделать схему и без GitHub вообще. Можно просто связать два репозитория друг с другом напрямую (только это сложнее в настройке)