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

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

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

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

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

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

Взгляните на то, как Рубин на Рельсах делает это.

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

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

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

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

• Назовите свои базы данных следующим образом - 'dev< < db> > tst< < db> > stg< < db> > prd< < db> &gt'; (Очевидно, Вы никогда не должны hardcode db имена
• Таким образом Вы были бы в состоянии развернуть даже другой тип db' s на том же физическом сервере (я не рекомендую, чтобы, но Вы могли иметь к..., если ресурсы трудны),
• Гарантируйте, что Вы были бы в состоянии переместить данные между теми автоматически
• Отделите db сценарии создания от населения =, должно быть всегда возможно воссоздать db с нуля и населить его (от старой db версии или внешнего источника данных
• не используйте hardcode строки подключения в кодексе (даже не в файлах конфигурации) - используют в шаблонах строки подключения файлов конфигурации, которые Вы действительно населяете динамично, каждая реконфигурация application_layer, который действительно должен повторно собрать, ПЛОХА
• действительно используйте управление версиями базы данных и управление версиями объектов db - если Вы можете предоставить его, используют готовые продукты, если не развивают что-то самостоятельно
• отследите каждое изменение DDL и спасите его в некоторый стол истории (пример здесь)
• ЕЖЕДНЕВНЫЕ резервные копии! Тест, как быстро Вы были бы в состоянии восстановить что-то потерянное из резервной копии (используют automathic, восстанавливает сценарии
• даже у Вашей базы данных DEV и НАПОМИНАНИЯ есть точно тот же сценарий создания, Вы будете иметь проблемы с данными, поэтому позволите разработчикам создавать точную копию напоминания и играть с ним (я знаю, что получу минусы для этого, но изменюсь в мышлении, и бизнес-процесс будет стоить Вам намного меньше, когда дерьмо поразит поклонника - так вынудите кодеры к нижнему индексу по закону независимо от того, что это делает, но гарантируйте этому

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

• 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 в отделении. ARGH!

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

Так, I' m не удовлетворенный этим также. Мне действительно нравится понятие миграций от Рельсов. I' ve становятся вполне очарованными LiquiBase. Это поддерживает понятие возрастающих рефакторингов базы данных. It' s стоящий взгляда и I' ll посмотреть на него подробно скоро. У кого-либо есть опыт с ним? I' d быть очень любопытным услышать о Ваших результатах.

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

I' m испуганный I' m в согласии с другими плакатами. Разработчикам нужны к сценарию их изменения.

Во многих случаях простое ИЗМЕНЯЕТ ТАБЛИЦУ won' t работа, Вы должны изменить существующие данные также - разработчикам нужно к вещи о том, какие миграции требуются и удостоверяются they' ре, подготовленное правильно (конечно, Вы должны проверить это тщательно в какой-то момент в цикле выпуска).

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

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

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

Разработчики развиваются в VM' s с частным DB' s.

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

Тестированием управляют на различных машинах (на самом деле в в VM' s принятый на сервере) [Будет скоро управляться сервером Hudson CI]

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

Тогда единица, которой управляют, и системные тесты.

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

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

Мы берем свалку схемы нашей DB песочницы. Тогда sql свалка данных. Мы разность это к предыдущему основанию. та пара дельт должна модернизировать n-1 до n.

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

Таким образом, чтобы установить версию N УБИРАЮТ, мы управляем свалкой в пустой db. Чтобы исправить, примените прошедшие участки.

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

Дельты и свалки должны быть рассмотрены перед эксплуатационным испытанием. Я can' t видят любой путь вокруг этого как I' ve замеченные разработчики вставляют испытательные счета в DB для себя.

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

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

Мы используем командную строку mysql-разность: это производит различие между двумя схемами базы данных (от живой DB или сценария), как ИЗМЕНЯЮТ сценарий. mysql-разность выполнена в прикладном начале, и если схема изменилась, это сообщает разработчику. Таким образом, разработчики не должны писать, ИЗМЕНЯЕТСЯ вручную, обновления схемы происходят полуавтоматически.

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

http://code.google.com/p/migrationscriptgenerator/SQL-сервер только I' m боящийся: (It' s также симпатичная альфа, но это - ОЧЕНЬ низкое трение (особенно, если Вы объединяете его с Тарантино или http://code.google.com/p/simplescriptrunner/),

Путем я использую его, должен иметь проект сценариев SQL в Вашем .sln. У Вас также есть db_next база данных в местном масштабе, которую Вы вносите своими изменениями в (использование Студии управления или [Экспорт Схемы NHibernate] [2] или LinqToSql CreateDatabase или что-то). Тогда Вы выполняете migrationscriptgenerator с _dev и _next DBs, который создает. SQL обновляют сценарии для перемещения через.

[2]: http://wiki.fluentnhibernate.org/show/GettingStarted: + First+Project

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

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

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

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