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

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

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

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

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

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

Если проблема была просто схемой, было бы проще, но в базе данных также были "базовые" данные, которые также обновляются во время разработки, такие как метаданные в таблицах безопасности и разрешений.

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

Следующий вопрос: как вы отслеживаете версии базы данных, чтобы вы знали, какие сценарии запускать для обновления данного экземпляра базы данных? Является ли таблица версий, подобная Lance, ниже стандартной процедуры?

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

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

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

ОТВЕТЫ

Ответ 1

Есть несколько хороших вариантов. Я бы не использовал стратегию "восстановить резервную копию".

  • Script все ваши изменения схемы и сервер CI запускает эти сценарии в базе данных. Имеет таблицу версий, чтобы отслеживать текущую версию базы данных и выполнять только сценарии, если они предназначены для более новой версии.

  • Используйте решение для переноса. Эти решения зависят от языка, но для .NET я использую Migrator.NET. Это позволяет вам обновлять вашу базу данных и перемещаться вверх и вниз между версиями. Ваша схема указана в коде С#.

Ответ 2

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

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

Ответ 3

Посмотрите, как Ruby on Rails делает это.

Сначала есть так называемые файлы миграции, которые в основном преобразуют схему базы данных и данные из версии N в версию N + 1 (или в случае понижения с версии N + 1 до N). В базе данных есть таблица, которая сообщает текущую версию.

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

Ответ 4

Книга " Рефакторинг баз данных: эволюционный дизайн баз данных" может дать вам некоторые идеи о том, как управлять базой данных. Краткая версия также доступна для чтения по адресу http://martinfowler.com/articles/evodb.html.

В одном проекте PHP + MySQL у меня был номер ревизии базы данных, сохраненный в базе данных, и когда программа подключается к базе данных, она сначала проверит ревизию. Если программа требует другой ревизии, она откроет страницу для обновления базы данных. Каждое обновление указывается в коде PHP, который изменит схему базы данных и перенесет все существующие данные.

Ответ 5

Вы также можете использовать инструмент SQL Compare to script разницу между различными версиями базы данных, что позволяет быстро мигрировать между версиями

Ответ 6

  • Назовите свои базы данных следующим образом - dev_<<db>>, tst_<<db>>, stg_<<db>>, prd_<<db>> (Очевидно, вам никогда не следует жестко кодировать имена db
  • Таким образом, вы сможете развернуть даже разные типы БД на одном и том же физическом сервере (я не рекомендую этого, но вам, возможно, придется... если ресурсы ограничены)
  • Убедитесь, что вы сможете перемещать данные между этими автоматическими
  • Отделите сценарии создания БД от совокупности = всегда должна быть возможность воссоздать БД с нуля и заполнить ее (из старой версии БД или из внешнего источника данных
  • не используйте строки кода с жестким кодом в коде (даже не в файлах конфигурации) - используйте в файлах конфигурации шаблоны строк подключения, которые вы заполняете динамически, каждая реконфигурация application_layer, которая требует перекомпиляции, BAD
  • используйте версионность баз данных и версионность объектов БД - если вы можете себе это позволить, используйте готовые продукты, если не разрабатываете что-то самостоятельно
  • отслеживать каждое изменение DDL и сохранять его в какой-либо таблице истории (пример здесь)
  • ЕЖЕДНЕВНЫЕ резервные копии! Проверьте, насколько быстро вы сможете восстановить что-то потерянное из резервной копии (используйте автоматические сценарии восстановления
  • даже у вашей базы данных DEV и PROD точно такой же сценарий создания, что у вас будут проблемы с данными, поэтому позвольте разработчикам создать точную копию prod и поиграть с ней (я знаю, что получу минусы для этого, но изменения в мышление и бизнес-процесс обойдутся вам гораздо дешевле, когда дерьмо ударит по фанату - так что заставьте кодеров легально подписывать все, что он делает, но убедитесь, что это

Ответ 7

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

  • dbChanges_1.sql
  • dbChanges_2.sql
  • ...
  • dbChanges_n.sql

Это работало достаточно хорошо, пока мы не начали поддерживать две линии разработки: Trunk/Mainline для новой разработки и ветвь обслуживания для исправлений ошибок, краткосрочные улучшения и т.д. Неизбежно возникла необходимость внести изменения в схему в филиал. На этом этапе у нас уже было dbChanges_n + 1.sql в Trunk, поэтому мы закончили с помощью следующей схемы:

  • dbChanges_n.1.sql
  • dbChanges_n.2.sql
  • ...
  • dbChanges_n.3.sql

Опять же, это сработало достаточно хорошо, пока мы в один прекрасный день не подняли глаза и увидели 42 сценария дельты в магистрали и 10 в ветке. ARGH!

В эти дни мы просто поддерживаем одну дельта script и предоставляем версию SVN - то есть мы перезаписываем script с каждой версией. И мы уклоняемся от изменения схемы в ветвях.

Итак, я тоже этого не доволен. Мне очень нравится концепция миграции из Rails. Я увлекся LiquiBase. Он поддерживает концепцию инкрементных рефакторингов баз данных. Это стоит посмотреть, и я скоро посмотрю на него. У кого-нибудь есть опыт? Мне было бы очень интересно узнать о ваших результатах.

Ответ 8

У нас очень похожая настройка для OP.

Разработчики разрабатываются в виртуальных машинах с частными БД.

[Разработчики скоро перейдут в частные ветки]

Тестирование выполняется на разных компьютерах (фактически в виртуальной машине, размещенной на сервере) [Скоро будет запущен сервер Hudson CI]

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

Затем запустите единичные и системные тесты.

Производство развертывается для клиентов как установщиков.

Что мы делаем:

Мы берем схему дампа нашей БД. Затем дамп данных sql. Мы сравниваем это с предыдущей базой. эта пара дельт должна обновить n-1 до n.

мы настраиваем дампы и дельта.

Итак, чтобы установить версию N CLEAN, мы запускаем дамп в пустой db. Для исправления применяйте промежуточные патчи.

(Юха сказал, что идея Rail о том, чтобы таблица, записывающая текущую версию БД, была хорошей, и должна сделать обновление установки менее чреватым.)

Дельта и свалки должны быть рассмотрены до бета-тестирования. Я не вижу никакого способа обойти это, поскольку я видел, как разработчики вставляют тестовые учетные записи в БД для себя.

Ответ 9

Боюсь, я согласен с другими плакатами. Разработчикам необходимо script внести изменения.

Во многих случаях простой ALTER TABLE не будет работать, вам также необходимо изменить существующие данные. Разработчики должны знать, какие миграции требуются, и убедиться, что они написаны правильно (конечно, вам нужно тщательно проверить это на некоторые моменты цикла выпуска).

Кроме того, если у вас есть какой-то смысл, вы также получите своих разработчиков к откатам script для их изменений, чтобы их можно было вернуть, если это необходимо. Это также должно быть проверено, чтобы гарантировать, что их откат не только выполняется без ошибок, но и оставляет БД в том же состоянии, в котором он был ранее (это не всегда возможно или желательно, но чаще всего является хорошим правилом).

Как вы подключаете это к серверу CI, я не знаю. Возможно, ваш CI-сервер должен иметь известный снимок сборки, который он возвращает к каждой ночи, а затем применяет все изменения с тех пор. Это, вероятно, лучше всего, в противном случае сломанная миграция script будет ломать не только эту ночную сборку, но и все последующие.

Ответ 10

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

Ответ 11

Посмотрите dbdeploy, уже есть инструменты Java и .net, вы можете следовать их стандартам для макетов файлов SQL и таблицу версий схемы и напишите свою версию python.

Ответ 12

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

Ответ 13

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

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

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

Ответ 14

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

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

  • для каждой схемы db получить схему ddls
  • поставьте его под версию contol

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