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

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

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

2. Используйте решение для миграции. Эти решения различаются в зависимости от языка, но для .NET я использую Migrator.NET. Это позволяет вам обновлять вашу базу данных и переходить от одной версии к другой. Ваша схема указана в коде C#.

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

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

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

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

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

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

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

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

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

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

Опять же, это работало достаточно хорошо, пока однажды мы не посмотрели и не увидели 42 дельта-скрипта в основной строке и 10 в ветке. АРГХ!

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

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

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

У нас очень похожая установка на OP.

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

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

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

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

Затем запустите модульные и системные тесты.

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

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

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

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

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

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

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

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

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

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

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

Вы также можете использовать такой инструмент, как Сравнение SQL, для создания сценария различий между различными версиями базы данных, что позволит вам быстро переходить между версиями.

Я написал инструмент, который (подключившись к Открыть DBDiff) сравнивает схемы базы данных и предлагает вам сценарии миграции. Если вы сделаете изменение, которое удаляет или изменяет данные, оно выдаст ошибку, но предоставит предложение для сценария (например, когда столбец отсутствует в новой схеме, он проверит, был ли столбец переименован, и создаст 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, который создает. сценарии обновления SQL для миграции.

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

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

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

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

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

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

1. для каждой схемы db получить схему ddls
2. поместите это под версией contol

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