Drupal очень многое позволяет делать из админки. Создание типов публикаций, представлений, настройка модулей и многое другое. Это сильная сторона и одновременно проклятие проектов на Drupal.
Многие разработчики, особенно когда речь идет о работе над проектом в команде, используют системы контроля версий. Для меня это, к примеру, GIT.
GIT отслеживает изменения файлов, отлично их понимает и умеет с ними работать. Что касается базы данных, то все изменения остаются за бортом GIT.
Синхронизация мета-данных
В базе хранится разнообразная информация. Бóльшую часть этих данных обычно отслеживать не нужно — это пользовательские данные, публикации, контент сайта, кеши, ревизии и т.п..
Потому применим подход, когда до очередного коммита создаётся сравнительный скрипт изменений структуры и данных в таблицах, отвечающих за структуру сайта. А при деплое изменений — этот скрипт выполняется (например, как часть какого то модуля MyModule.install).
Этот подход вполне успешен и применяется. Какие ещё есть варианты?
Использование одной базы
Иногда используют для dev и production версии сайта одну и ту же базу данных.
Очень спорный подход, позволяет решить сложности с переносом конструктивных изменений сайта, которые хранятся в базе. Но эволюция изменений остаётся за бортом GIT.
Существует большой риск «уронить» продакш сервер, что то испортить на действующем сайте во время разработки. Не решаются конфликты версий нескольких разработчиков, т.к. они могут параллельно начать модификацию одних и тех же объектов через админку Drupal или напрямую в базе.
Модуль Features
И ещё несколько десятков модулей, которые поддерживают концепцию features :)
Идея заключается в том, чтобы генерировать PHP код структурных изменений в виде отдельных модулей. Формируется код не на SQL, а на PHP с использованием разных Drupal-core и contributed APIs.
Как оказывается, многие модули поддерживают Features намеренно или «случайно», работая с базовыми Drupal API. Вы также можете написать свои «мосты» для Features, если разрабатываете что то совсем кастомное и не укладывающееся в типичные структуры данных CMS.
Для чего можно использовать подход, реализуемый модулем Features:
- Конструктор публикаций, типы публикаций, поля;
- Коллекции полей;
- Представления (модуль views);
- Словари (таксономия);
- Переменные (выборочные данные таблицы variable);
- Меню, пункты меню;
- Настройки модуля context;
- Настройки модуля node_queue;
- Права и роли пользователей;
- Стили изображений;
- Контент (избранные публикации вместе со всеми данными — картинками, текстами и т.д.)
- и многое другое.
Вот пример набора доступных компонентов в одном из проектов для создания модуля через feature:
Какие то связи features распознаёт сам. К примеру, достаточно указать тип публикации — и в создаваемый модуль будет добавлены описания полей. Если какие то описания полей уже объявлены в другой «фиче», то создаваемый модуль получит от него зависимость. Другие же связи можно добавлять вручную, выбирая их из списка.