Drupal инструмент для развертывания / тестирования / «как не называть»

Question

Настройка следующая: Проект Drupal, одно svn-репо с ветками trunk / qa / production-ready, vhosts для каждой ветки, ловушка после фиксации, которая копирует файлы из репозитория в docroots.

Проблема заключается в следующем: веб-сайт Drupal часто опирается не только на исходный код, но и на данные БД (типы узлов, их настройки и т. Д.).

Я ищу решение, чтобы сделать эти изменения версионными. Но это не похоже на «разметку» всех данных в базе данных, а на что-то вроде фикстур в модульных тестах.

Фиксированные скриптовые сценарии с данными и файлами SQL для контента, который должен быть версионным и применяться после основной ловушки после фиксации.

Есть ли что-нибудь написанное для этой цели, или, возможно, было бы легко адаптировать какой-либо инструмент для сборки (например, Apache Ant) или инфраструктуру для модульного тестирования. И было бы очень здорово, если бы этот инструмент знал о drupal, поэтому в скриптах я могу делать такие вещи, как variable_set(), drupal_execute().

Есть идеи? Или я должен начать кодировать прямо сейчас, а не спрашивать об этом? :)

Answer 1

Похоже, у вас уже есть какая-то инфраструктура, которую вы написали.

Так что я бы начал кодировать! На данный момент я не знаю ничего такого, что было бы особенно полезно для этого. И если это произойдет, я думаю, что потребуется приложить некоторые усилия, чтобы привести его в соответствие с существующей инфраструктурой. Таким образом, начало кодирования кажется правильным.

Мой подход к этому - использовать файлы исправлений sql (файлы, содержащие операторы sql для обновления схемы / данных БД) с номером версии в начале имени файла. Затем база данных содержит таблицу с информацией о конфигурации (возможно, она у вас уже есть), которая включает информацию о том, в какой версии находится база данных.

Затем вы можете использовать несколько подходов, чтобы автоматически применить патч. Одним из них может быть скрипт, который вы вызываете из postcommit, который проверяет версию базы данных, а затем проверяет, является ли последняя версия, для которой у вас есть исправление, более новой, чем версия, в которой находится база данных, и применяет ее / их по порядку) если так.

Патч db всегда должен заканчиваться обновлением вышеупомянутого номера версии в таблице конфигурации.

Этот подход можно расширить, включив в него возможность настроить новую базу данных на основе файла полного дампа, а затем применить к нему все необходимые исправления для его обновления.

Answer 2

Сделал презентацию по этому вопросу на недавней конференции ( ссылка на слайдшер ) - я НАСТОЯТЕЛЬНО рекомендую использовать специфический для сайта пользовательский модуль, чей файл .install содержит версионные функции «обновления», которые выполняют тяжелая работа для изменений схемы базы данных и настроек / изменений конфигурации.

Определенно лучше хранить файлы .sql, потому что Drupal будет отслеживать, какие из них были запущены, и дает вам механизм пакетной обработки для всего, что требует длительных массовых операций с большим количеством данных.

Answer 3

Ранее: Стратегия управления исходным кодом Drupal?

Answer 4

Возможно, вы захотите проверить книгу Рефакторинг баз данных .

Совет, который я услышал от одного из авторов, заключается в том, чтобы иметь скрипт, который будет обновлять базу данных от версии к версии, а не создавать ее с нуля каждый раз.

Answer 5

Мой подход к этому - использовать файлы исправлений sql (файлы, содержащие операторы sql для обновления схемы / данных БД) с номером версии в начале имени файла.

Я думал о файле (xml или что-то) с необходимой структурой БД и инструменте, который применяет необходимые изменения.

И да, после дополнительных исследований я согласен: это будет легче закодировать, чем адаптировать некоторые другие решения. Хотя некоторые подпрограммы из simpletest drupal модуля будут полезны, я думаю.