Re: Разработка сайта с помощью сервиса контроля версий (git и т.д.)
Версионирование БД это в целом довольно специфичная тема, решений для этого существует немного, и практически все они основаны на одном и том же подходе - делается дамп БД в текстовые файлы и уже они хранятся в системе контроля версий.
Поэтому чаще всего используют другой подход - сохраняют в отдельные сценарии набор запросов, которыми изменяют БД на хосте разработки, а в момент выкатывания изменений на продакшен выполняют эти же запросы в боевой БД, и при необходимости запускают специальные скрипты прокачки данных в таблицах.
Re: Разработка сайта с помощью сервиса контроля версий (git и т.д.)
Т.е. вы первый вариант не рекомендуете? Я если честно вообще git не пользуюсь, поэтому для меня это всё пока что тёмный лес, но вот со мной работает несколько человек и хотелось бы следить за тем кто какие изменения вносил.
А можете тогда какие-то материалы порекомендовать по теме, может статьи есть.
И если честно я не понимаю как можно сохранять запросы к бд если мы будем работать через ядро HOSTCMS, создавать доп.свойства, узлы и т.д.
Можно конечно БД хранить в стороннем месте а работать только с дизайном и скриптами и только их отслеживать, но это какие-то полумеры получатся.
Re: Разработка сайта с помощью сервиса контроля версий (git и т.д.)
Маяковский, первый вариант я не то чтобы не рекомендую, а просто не встретил пока ни одного инструмента который был бы для этого удобен и приносил в итоге пользы больше чем геммороя.
Что касается материалов по теме - про гит есть хорошее русскоязычное руководство - а также удобные клиенты с графическим интерфейсом, как альтернатива классической консоли, например или очень удобный клиент, встроенный в среду разработке PhpStorm.
Про запросы к БД - я имел в виду совершенно не те, запросы, которые вы делаете через ядро системы в процессе работы сайта, а изменения схемы БД и внесение некоторых категорий данных.
Смысл тут вот в чем.
1. Про схему. Реляционная база данных состоит из таблиц с данными, между которыми есть некоторые связи. У таблиц есть набор полей разных типов. Вот сама структуры таблиц без данных - это схема базы. Если вашему разработчику, для каких-то нужд потребовалось завести новую таблицу в базе, или добавить/изменить какое-то поле в уже существующей таблице, то это тоже делается SQL-запросом, но, как правило, не через ядро самой CMS а через какой-нибудь удобный инструмент администрирования базы, например, phpMyAdmin.
Вот такие запросы сохраняются в отдельный файл, который и будет сохранен в систему контроля версий. Файл будет специфичен именно для какого-то конкретного набора изменений на сайте. Например вы разрабатывали какой-то модуль, и для него нужно завести пару таблиц в БД. Вся разработка модуля ведется в отдельной ветке в системе контроля версий, и в этой же ветке будет и файл с изменениями схемы БД. В момент момент деплоя этой ветки на продакшен, вы должны будете не только выложить код, но и выполнить запросы из этого файла. Но это уже скорее не про контроль изменений а про скрипты сборки и выкладки.
2. Про данные. Часть служебных данных системы тоже хранится в БД. Например, вы создали новый XSL-шаблон, и у вас при этом появились две сущности - файл .xsl в папке /hostcmsfiles/xsl и новая строчка в БД в таблице xsls. При этом имя файла равняется идентификатору этой строки в таблице. Файл попадет под контроль версий сам, а вот появление записи в таблице нужно отследить самостоятельно, и в отдельном файле сохранить тот запрос, который добавляет в таблицу эту запись, чтобы в момент деплоя выполнить и его тоже. Технически тут могут быть разные варианты, можно отслеживать это самостоятельно, можно попробовать написать какой-нибудь хук к БД для сохранения запросов к определенным таблицам, можно просто перед деплоем делать дампы нужных таблиц из БД на бою и на две-сервере, и сравнивать их. Тут, по-хорошему, надо бы воспользоваться и системой разграничения прав пользователей в админке, чтобы, например, создавать XSL-шаблоны мог только пользователь на дев-сервере а на продакшене не мог никто. Иначе в какой-то момент в боевой и в разработческой базах разные люди создадут два разных шаблона но у них будет один и тот же идентификатор, и это приведет к конфликтам, разруливать которые придется вручную.
