Отслеживание и развертывание кода и данных
В течение долгого времени мы хранили наши данные в хранилище проекта. Мы просто хранили все в data / sql, и у каждой таблицы были свои собственные файлы create_tablename.sql и data_tablename.sql.
Мы только что развернули наш второй проект на Scalr, и мы поняли, что он немного грязный.
Способ развертывания:
У нас есть «пакетная» коллекция скриптов, которые разбивают проект на 3 архива (данные, код, статические файлы), которые мы затем храним в 3 отдельных корзинах на S3.
Каждый раз, когда роль запускается, она загружает один из файлов (в зависимости от роли: данные, nfs или сеть), а затем настраивается сценарий «распаковки». все для каждой роли, загружает данные в mysql, устанавливает nfs и т. д.
Мы делаем это так, потому что мы не хотим сохранять образы серверов, мы всегда начинаем с ванильных экземпляров, на которые мы устанавливаем все с нуля. используя различные встроенные скрипты. Время запуска не является проблемой (у нас есть готовая к использованию ферма за 9 минут).
Проблема в том, что каждый раз, когда мы пытаемся настроить новую сборку разработки, трудно найти нужную версию базы данных (в в любой момент времени у нас есть около 4 сборок для проекта). Кроме того, мерзавец начинает задыхаться, когда мы идем в производство, поскольку файлы sql заканчиваются общим объемом около 500 МБ.
Вопрос:
Как все остальные управляют базами данных? Я искал что-то, что облегчает перенос данных из производства в dev, а также перенос данных из dev в производство, но ни на что не наткнулся.
5 ответов
Вам следует серьезно взглянуть на dbdeploy (dbdeploy.com). Он перенесен на многие языки, основными из которых являются Java и PHP. Он интегрирован в инструменты сборки, такие как Ant и Phing, и позволяет легко обмениваться так называемыми дельта-файлами.
Дельта-файл всегда состоит из раздела развертывания, но может также содержать раздел отмены. Когда вы фиксируете свой дельта-файл и другой разработчик проверяет его, он может просто запустить dbdeploy, и все новые изменения автоматически применяются к его базе данных.
Я использую dbdeploy для своего блога с открытым исходным кодом, поэтому вы можете посмотреть, как организованы дельта-файлы: http://site.svn.dasprids.de/trunk/sql/deltas/
Отъезд капистрано . Это инструмент, который сообщество Ruby использует для развертывания в различных средах, и я считаю его действительно полезным.
Также, если ваше развертывание начинает задыхаться, попробуйте встроенный в Twitter инструмент под названием Murder .
Насколько я понимаю, ваш главный вопрос - это опыт других людей в переносе данных SQL из разработчика в производство.
Я использую 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-скрипт для изменения данных. Вы можете легко исключить некоторые таблицы или столбцы из сравнения. Вы также можете проверить результаты и исключить некоторые записи из генерации скрипта. Таким образом, можно легко и гибко создавать сценарии, которые можно использовать для развертывания изменений в базе данных. Вы можете отдельно сравнивать данные двух баз данных из структуры (сравнение схем). Таким образом, вы можете обновить данные в dev с помощью данных из prod или сгенерировать скрипты, которые изменяют базу данных prod до последней версии базы данных dev. Я рекомендую вам ознакомиться с этими функциями и некоторыми продуктами http://www.red-gate.com/ (например, http://www.red-gate.com/products/SQL_Compare /index.htm).
Лично я бы посмотрел на Toad
Менее 10k;) ... проанализирует структуры базы данных, создаст сценарии для изменения их, а также будет переносить данные.
Одной из частей решения является фиксация версии каждого из ваших модулей кода и соответствующих им ресурсов данных в одном месте и их сравнение для обеспечения согласованности. Например, увеличение номера версии вашего, скажем, customer_comments модуля потребует соответствующего дельта-файла SQL для обновления соответствующих таблиц БД до равного номера версии данных.
Для примера посмотрите на core_resource подход Magento, документированный @AlanStorm.
Будьте здоровы, JD