Контроль и развертывание кода и данных

Долгое время мы хранили наши данные в репозитории проекта. Мы просто держали все под данными /sql, и каждая таблица имела свои файлы create_tablename.sql и data_tablename.sql.

Теперь мы только что развернули наш второй проект на Scalr, и мы поняли, что это немного грязно.

Способ развертывания:

У нас есть "пакетная" коллекция скриптов, которые разрывают проект на 3 архива (данные, код, статические файлы), которые мы затем сохраняем в 3 отдельных ведрах на S3.

Всякий раз, когда роль запускается, она загружает один из файлов (в зависимости от роли: данные, nfs или web), а затем "распаковка" script устанавливает все для каждой роли, загружает данные в mysql, устанавливает up nfs и т.д.

Мы делаем это так, потому что мы не хотим сохранять образы серверов, мы всегда начинаем с экземпляров ванили, на которые мы устанавливаем все с нуля, используя различные встроенные скрипты. Время запуска не является проблемой (у нас есть готовая ферма в 9 минут).

Проблема заключается в том, что боль пытается найти нужную версию базы данных всякий раз, когда мы пытаемся установить новую конструкцию разработки (в любой момент времени у нас есть около 4 сборщиков для проекта). Кроме того, git начинает задыхаться, когда мы входим в производство, так как файлы sql в итоге составляют около 500 МБ.

Возникает вопрос:

Как все остальные управляют базами данных? Я искал что-то, что позволяет легко выводить данные из производства в dev, а также переносить данные из dev в производство, но не наткнулся на что-либо.

Ответ 1

Вам следует серьезно взглянуть на dbdeploy (dbdeploy.com). Он портирован на многие языки, основными из которых являются Java и PHP. Он интегрирован в инструменты построения, такие как Ant и Phing, и позволяет легко обмениваться так называемыми дельта файлами.

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

Я использую dbdeploy для своего блога с открытым исходным кодом, поэтому вы можете посмотреть, как организованы файлы дельты: http://site.svn.dasprids.de/trunk/sql/deltas/

Ответ 2

Насколько я понимаю, ваш главный вопрос - это опыт других людей в переносе данных SQL из dev в производство.

Я использую Microsoft SQL Server вместо My SQL, поэтому я не уверен, что мой опыт вы можете использовать напрямую. Тем не менее этот способ работает очень хорошо.

Я использую Visual Studio 2010 Ultimate для сравнения данных в двух базах данных. Та же функция существует и в Vinsual Studio Team Edition 2008 (или в редакции базы данных). Вы можете прочитать http://msdn.microsoft.com/en-us/library/dd193261.aspx, чтобы понять, как это работает. Вы можете сравнить две базы данных (dev и prod) и сгенерировать SQL Script для изменения данных. Вы можете легко исключить из сравнения некоторые таблицы или некоторые столбцы. Вы также можете просмотреть результаты и исключить некоторые записи из поколения script. Таким образом, можно легко и гибко генерировать скрипты, которые могут использоваться для развертывания изменений в базе данных. Вы можете отдельно сравнить данные двух баз данных из структуры (сравнение схемы). Таким образом, вы можете обновлять данные в dev с данными из prod или генерировать скрипты, которые изменяют базу данных prod до последней версии базы данных dev. Я рекомендую вам ознакомиться с этими функциями и некоторыми продуктами http://www.red-gate.com/ (например http://www.red-gate.com/products/SQL_Compare/index.htm).

Ответ 3

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

Также, если ваше развертывание начинает дросселировать, попробуйте инструмент twitter, построенный под названием Murder.

Ответ 4

Лично я бы посмотрел на Toad

http://www.toadworld.com/

Менее 10 тыс.;...... будет анализировать структуры базы данных, создавать сценарии для их изменения, а также переносить данные.

Ответ 5

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

В качестве примера рассмотрим Magento core_resource подход, как описано в @AlanStorm.

Cheers, JD