Контроль версий фронт-энда для CMS
Я ищу методологию наилучшей практики для управления версиями для нескольких разработчиков, работающих вместе на веб-сайтах на основе CMS.
Таким образом, у нас есть несколько сайтов на основе CMS в активной разработке. Если вам интересно, CMS это DNN. На нашем тестовом сервере у нас есть внешние разработчики, работающие с CSS, JS, а также добавляющие контент на страницы, который, конечно, хранится в базе данных. У нас также есть разработчики модулей, которые имеют локальные копии исходной И базы данных, где они разрабатывают и продвигают на тестовый сервер. И у нас есть TFS-сервер, на котором разработчики модулей могут разместить свои репозитории для контроля версий.
У меня вопрос, как мне получить фронтенд-разработчиков по управлению версиями? Они не могут иметь локальные версии базы данных, потому что все их обновления контента (базы данных) будут постоянно не синхронизированы с тестовым сервером. Для них нереально создать сценарии изменений для своих обновлений контента / страниц для базы данных (не говоря уже о том, что это другой набор навыков, и он побеждает цель удобства использования CMS). Они не могут разместить все локальные копии файлов и затем подключиться к общей удаленной БД, потому что приложение использует кэш-память... которая была бы... как вы уже догадались... не синхронизирована.
Мне кажется, что я что-то здесь упускаю, потому что другие организации должны как-то это делать. Нам абсолютно необходим контроль версий наших ресурсов JS/CSS.
Благодарю.
1 ответ
У вас фактически есть два набора работы, которые следует рассматривать отдельно.
Первая - это ваша версия DNN и настройки, которые вы делаете. Они должны храниться в системе контроля версий, и вы должны создать конвейер развертывания для передачи битов от сборки к серверам.
Второе - это ваши настройки в приложении, которые выполняются с помощью point'n'click. Они не являются версиями в традиционном смысле и должны рассматриваться как специфические для экземпляра. Вы можете и, вероятно, должны написать все настройки данных и версий. Таким образом, у вас будет папка для каждого экземпляра, который вы отправляете с указанием состояния, если данные на момент отправки.