Как вы управляете базами данных при разработке, тестировании и производстве?

Question

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

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

Мы хотим развернуть сервер разработки с непрерывной интеграцией, на котором всегда будет работать последний принятый код. Если мы сделаем это сейчас, он перезагрузит базу данных из SVN для каждой сборки.

У нас есть тестовый (виртуальный) сервер, который запускает «кандидатов на выпуск». Развертывание на тестовом сервере в настоящее время является очень ручным процессом и обычно включает в себя загрузку последней версии SQL из SVN и ее настройку. Кроме того, данные на тестовом сервере противоречивы. В результате вы получите все тестовые данные, которые последний разработчик зафиксировал на своем сервере-песочнице.

Там, где все рушится, это развертывание в производство. Поскольку мы не можем перезаписать текущие данные тестовыми данными, это предполагает ручное воссоздание всех изменений схемы. Если было большое количество изменений схемы или сценариев преобразования для манипулирования данными, это может стать очень проблематичным.

Если бы проблема была только в схеме, это была бы более простая проблема, но в базе данных есть «базовые» данные, которые также обновляются во время разработки, например метаданные в таблицах безопасности и разрешений. *

Это самый большой барьер, который я вижу при переходе к непрерывной интеграции и пошаговой сборке. Как вы решаете это?

---

Дополнительный вопрос: как вы отслеживаете версии базы данных, чтобы знать, какие сценарии нужно запустить для обновления данного экземпляра базы данных? Таблица версий, как упоминает Ланс, ниже стандартной процедуры?

---

Спасибо за ссылку на Тарантино. Я не нахожусь в среде .NET, но нашел их DataBaseChangeMangement wiki page очень полезными. Особенно это PowerPoint Presentation (.ppt)

Я собираюсь написать сценарий Python, который проверяет имена *.sql сценариев в заданном каталоге по таблице в базе данных и запускает те, которых там нет, по порядку на основе целого числа, которое формирует первое часть имени файла. Если это довольно простое решение, как я подозреваю, оно будет опубликовано здесь.

---

У меня есть рабочий скрипт для этого. Он обрабатывает инициализацию БД, если она не существует, и запускает сценарии обновления по мере необходимости. Есть также переключатели для очистки существующей базы данных и импорта тестовых данных из файла. В нем около 200 строк, поэтому я не буду его публиковать (хотя, если есть интерес, я могу поместить его в pastebin).

Answer 1

Если вы находитесь в среде .NET, то решением будет Тарантино . Он обрабатывает все это (включая сценарии SQL для установки) в сборке NANT.

Answer 2

Для базы данных oracle мы используем oracle-ddl2svn tools.

Этот инструмент автоматизировал следующий процесс

1. для каждой схемы БД получить схему ddls
2. поставить его под версию control

изменения между экземплярами разрешены вручную

Answer 3

Мы используем командную строку mysql-diff : она выводит разницу между двумя схемами базы данных (из действующей БД или скрипта) в качестве скрипта ALTER. mysql-diff выполняется при запуске приложения, и если схема изменилась, он сообщает об этом разработчику. Таким образом, разработчикам не нужно писать ALTERs вручную, обновления схемы происходят полуавтоматически.

Answer 4

Я написал инструмент, который (подключаясь к Open DBDiff ) сравнивает схемы базы данных и предложит вам сценарии миграции. Если вы внесете изменение, удаляющее или изменяющее данные, оно выдаст ошибку, но предоставит подсказку для сценария (например, если столбец отсутствует в новой схеме, он проверит, был ли столбец переименован, и создаст xx-сгенерированный script.sql.suggestion, содержащий оператор переименования).

http://code.google.com/p/migrationscriptgenerator/ Я боюсь только SQL Server :( Это тоже довольно альфа, но это ОЧЕНЬ низкое трение (особенно, если вы комбинируете его с Tarantino или http://code.google.com/p/simplescriptrunner/)

То, как я его использую, заключается в том, чтобы в вашем .sln был проект сценариев SQL. У вас также есть локальная база данных db_next, в которую вы вносите изменения (используя Management Studio или Экспорт схемы NHibernate или LinqToSql CreateDatabase или что-то в этом роде). Затем вы запускаете migrationscriptgenerator с базами данных _dev и _next, который создает. сценарии обновления SQL для миграции.