Как использовать контроль исходного кода в Joomla, предоставляя пользователям возможность продолжать вносить изменения в содержимое на рабочем сервере?
Все,
У меня есть проблема, с которой, я надеюсь, вы сможете мне помочь.
Сценарий:
Моя команда управляет несколькими сайтами Joomla для наших клиентов. Пока мы управляем разработкой / размещением сайтов, клиенты выполняют все обновления контента (создание статей, контента, загрузка изображений и т. Д.)
Мы запускаем эти сайты в следующей стандартной конфигурации, где мы имеем
- Сервер разработки
- Промежуточный сервер
- Производственный сервер
Клиент выполняет все обновления контента на производственном сервере (ежедневно). Два других сервера используются в основном для новых разработок и тестирования.
В настоящее время мы используем BitBucket в качестве SVN для этих сайтов (мы только начинаем с этого). В настоящее время все файлы, относящиеся к сайту, хранятся в репо.
Эта проблема
Исходя из наших текущих настроек, если разработчик вносит изменения в среду разработки и этот набор изменений затем переносится в производственную среду, мы в конечном итоге перезаписываем все обновления контента, которые наши клиенты сделали в производственной среде.
Мой вопрос
Как мы успешно используем систему контроля версий и поддерживаем гибкость, позволяющую нашим клиентам продолжать вносить обновления непосредственно на рабочий сервер, не вынуждая их вносить изменения в контент на этапе разработки, подготовки и производства?
Решение
Хотя вы кратко описали свой рабочий процесс, есть несколько вещей, которые следует учитывать. Там нет общего правила, но посмотрите на следующие предложения:
-
Включите в систему управления версиями ПРОСТО разработанные вами расширения (шаблон, компоненты, плагины и т. Д.). В любом случае, настройки — это единственное, что вы добавляете в Joomla. Надеюсь, без основных хаков. В качестве альтернативы, если вы действительно хотите создать версию всей установки, вы должны по крайней мере игнорировать папки мультимедиа, которые были изменены клиентами / вами. Я не вижу необходимости ставить весь сайт Joomla под контроль версий.
-
Я полагаю, что ваши клиенты на самом деле не меняют сценарии PHP, а только медиафайлы и записи в базе данных. Вы должны только подтолкнуть к производственному коду и / или изменениям схемы базы данных.
-
Если вы полагаетесь на функцию фиксации нажатия на FTP или ручную отправку файлов, я бы посоветовал изучить возможность создания распространяемой версии ваших изменений в форме пакета, который можно развернуть с помощью диспетчера расширений. Сборка пакетов может быть выполнена в один клик с помощью инструмента, такого как Phing. Например, если вы сделаете некоторые изменения в шаблоне, создадите новую версию шаблона, создадите пакет и сначала обновите промежуточный сервер / тестовый сервер и, если все пойдет хорошо, производство.
Другие решения
Некоторые вещи не должны быть в управлении версиями.
В общем, исходный код должен быть версионным и данные не следует. Я не знаком с Joomla, но любой каталог «загруженного контента» должен быть в файле игнорирования для вашей системы контроля версий. Таким образом, вы можете развернуть изменения в программном обеспечении, не беспокоясь о перезаписи данных.
Конечно, ваши данные должны регулярно создаваться резервные копии, но это не то, для чего нужен контроль версий.
Если у вас есть
- промежуточный сервер, на котором вы тестируете изменения сайта (макет, новая функциональность, новый css)
- производственный сервер, на котором пользователь публикует новый контент
Вам необходимо частичное обновление базы данных вместе с синхронизацией файлов.
База данных довольно сложная, так как на таблицу ресурсов могут влиять как изменения конфигурации на промежуточном сервере, так и новое содержимое на рабочем сервере; для этой и любых других общих таблиц мы решаем проблему, следя за тем, чтобы идентификаторы не конфликтовали сразу после обновления, оставляя достаточный пробел.
Хотя, цитируя большинство других ответов, контроль версий не предназначен ни для данных, ни для базы данных, он действительно очень полезен, особенно с хуками до и после фиксации для выполнения необходимых действий базы данных; тем не менее, любые инструменты написания сценариев / публикации, переходящие от rsync-rdiff к phing к ant — maven, подойдут