Инструмент развертывания / тестирования / не-как называть это Drupal
Настройка следующая: Проект Drupal, одно репозиторий svn с ветками, готовыми к trunk / qa / production, vhosts для каждой ветки, обработчик post-commit, который копирует файлы из репозитория в docroots.
Проблема в следующем: сайт Drupal часто полагается не только на исходный код, но и на данные БД (типы узлов, их настройки и т. д.).
Я ищу решение, чтобы сделать эти изменения версионными. Но не как «различать» все данные в базе данных, а как что-то вроде фикстур в модульных тестах.
Скрипты, подобные Fixture, с данными SQL и файлами для контента, который должен поддерживать версии и применяться после основного хука после фиксации.
Написано ли что-нибудь для этой цели, или, может быть, будет легко адаптировать какой-нибудь инструмент сборки (например, Apache Ant) или фреймворк для модульного тестирования. И было бы очень здорово, если бы этот инструмент знал о drupal, чтобы в скриптах я мог делать такие вещи, как variable_set(), drupal_execute().
Любые идеи? Или мне лучше начать писать код прямо сейчас, а не спрашивать об этом? :)
Ответы 5
Похоже, у вас уже есть инфраструктура, которую вы написали.
Итак, я бы начал кодировать! На данный момент я не знаю ничего особенно подходящего для этого. И если есть, я полагаю, что потребуются некоторые усилия, чтобы заставить это работать с вашей существующей инфраструктурой. Итак, начало написания кода кажется правильным.
Мой подход к этому - использовать файлы патчей sql (файлы, содержащие операторы sql для обновления схемы / данных db) с номером версии в начале имени файла. Затем база данных содержит таблицу с информацией о конфигурации (возможно, она у вас уже есть), которая включает информацию о версии, в которой находится база данных.
Затем вы можете использовать несколько подходов для автоматического применения патча. Один из них - это скрипт, который вы вызываете из посткоммита, который проверяет версию, в которой находится база данных, а затем проверяет, является ли последняя версия, для которой у вас есть патч, новее, чем версия, в которой находится база данных, и применяет ее / их ( по порядку) если так.
Патч db всегда должен заканчиваться обновлением вышеупомянутого номера версии в таблице конфигурации.
Этот подход можно расширить, включив в него возможность настроить новую базу данных на основе файла полного дампа, а затем применить к ней любые необходимые исправления для ее обновления.
My approach to this is to use sql patch files (files containing the sql statements to upgrade the db schema/data) with a version number at the start of the filename.
Я думал о файле (xml или что-то в этом роде) с необходимой структурой БД и инструментом, который вносит необходимые изменения.
И да, после дополнительных исследований я согласен: его будет легче закодировать, чем адаптировать некоторые другие решения. Хотя некоторые подпрограммы из модуля drupal самый простой будут полезны, я думаю.
Возможно, вы захотите почитать книгу Рефакторинг баз данных.
Совет, который я услышал от одного из авторов, состоит в том, чтобы иметь сценарий, который будет обновлять базу данных от версии к версии, а не создавать каждый раз с нуля.
Сделал презентацию по этому поводу на недавней конференции (ссылка на слайдшеринг) - Я НАСТОЯТЕЛЬНО предлагаю вам использовать специализированный модуль для конкретного сайта, чей файл .install содержит версионные функции обновления, которые выполняют тяжелую работу по изменению схемы базы данных и настройкам / конфигурации изменения.
Это определенно лучше, чем хранить файлы .sql, потому что Drupal будет отслеживать, какие из них были запущены, и дает вам механизм пакетной обработки для всего, что требует длительных массовых операций с большим количеством данных.
Проблема с Drupal заключается в том, что почти все хранится в БД, и часто бывает трудно различить конфигурацию, контент и «одноразовые вещи» (кеши, журналы и т. д.). Чтобы усложнить задачу, у вас часто бывает контент, созданный пользователями, с использованием тех же последовательностей идентификаторов, что и для «внутренних» материалов.