Отслеживание / развертывание кода и данных
В течение долгого времени мы хранили наши данные в репозитории проекта. Мы просто хранили все в data/sql, и у каждой таблицы были свои файлы create_tablename.sql и data_tablename.sql.
Мы только что развернули наш второй проект на Scalr, и мы поняли, что он немного грязный.
Как мы развернем:
У нас есть "пакетная" коллекция скриптов, которые разбивают проект на 3 архива (данные, код, статические файлы), которые мы затем храним в 3 отдельных корзинах на S3.
Каждый раз, когда роль запускается, она загружает один из файлов (в зависимости от роли: data, nfs или web), а затем сценарий "unpackage" устанавливает все для каждой роли, загружает данные в mysql, устанавливает nfs и т. Д.,
Мы делаем это так, потому что мы не хотим сохранять образы серверов, мы всегда начинаем с ванильных экземпляров, на которые мы устанавливаем все с нуля, используя различные встроенные скрипты. Время запуска не является проблемой (у нас есть готовая ферма за 9 минут).
Проблема в том, что каждый раз, когда мы пытаемся настроить новую сборку разработки, трудно найти подходящую версию базы данных (в любой момент времени у нас есть около 4 сборок для проекта). Кроме того, git начинает задыхаться, когда мы начинаем работать, так как файлы sql занимают около 500 МБ.
Вопрос в том:
Как все остальные управляют базами данных? Я искал что-то, что позволило бы легко переносить данные из производства в dev, а также переносить данные из dev в производство, но ни на что не наткнулся.
5 ответов
Вы должны серьезно взглянуть на dbdeploy (dbdeploy.com). Он портирован на многие языки, основными из которых являются Java и PHP. Он интегрирован в инструменты сборки, такие как Ant и Phing, и позволяет легко обмениваться так называемыми дельта-файлами.
Дельта-файл всегда состоит из раздела развертывания, но также может содержать раздел отмены. Когда вы фиксируете свой дельта-файл, и другой разработчик проверяет его, он может просто запустить dbdeploy, и все новые изменения автоматически применяются к его базе данных.
Я использую dbdeploy для моего блога с открытым исходным кодом, чтобы вы могли посмотреть, как организованы дельта-файлы: http://site.svn.dasprids.de/trunk/sql/deltas/
Насколько я понимаю, ваш главный вопрос - опыт других людей в переносе данных SQL из dev в рабочую среду.
Я использую Microsoft SQL Server вместо My SQL, поэтому я не уверен, что мой опыт вы можете использовать напрямую. Тем не менее, этот способ работает очень хорошо.
Я использую Visual Studio 2010 Ultimate Edition для сравнения данных в двух базах данных. Эта же функция существует и в Vinsual Studio Team Edition 2008 (или в базе данных). Вы можете прочитать http://msdn.microsoft.com/en-us/library/dd193261.aspx чтобы понять, как это работает. Вы можете сравнить две базы данных (dev и prod) и сгенерировать SQL Script для изменения данных. Вы можете легко исключить некоторые таблицы или столбцы из сравнения. Вы также можете просмотреть результаты и исключить некоторые записи из генерации скрипта. Таким образом, можно легко и гибко создавать сценарии, которые можно использовать для развертывания изменений в базе данных. Вы можете отдельно сравнить данные двух баз данных из структуры (сравнение схем). Таким образом, вы можете обновить данные в dev данными из prod или сгенерировать сценарии, которые изменяют базу данных prod до последней версии базы данных dev. Я рекомендую вам ознакомиться с этими функциями и некоторыми продуктами http://www.red-gate.com/ (например, http://www.red-gate.com/products/SQL_Compare/index.htm).
Проверьте Капистрано. Это инструмент, который сообщество ruby использует для развертывания в различных средах, и я считаю его действительно полезным.
Также, если ваше развертывание начинает задыхаться, попробуйте инструмент Twitter, созданный под названием Murder.
Одной из частей решения является сбор версии каждого из ваших модулей кода и соответствующих им ресурсов данных в одном месте и сравнение их для обеспечения согласованности. Например, увеличение номера версии вашего, скажем, customer_comments Модуль потребует соответствующего дельта-файла SQL для обновления соответствующих таблиц БД до равного номера версии данных.
Для примера, посмотрите на Magento's core_resource подход, задокументированный @AlanStorm.
Приветствия, JD
Лично я бы посмотрел на жабу
Менее 10k;) ... проанализирует структуры базы данных, создаст сценарии для их изменения, а также перенесет данные.