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

Question

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

Мой вопрос: каковы советы и рекомендации, чтобы держать базу в ногу с кодом? Как насчет того, чтобы откатить код? Ветвление?

Answer 1

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

Когда вы выпускаете в производство, у вас есть план отката на случай непредвиденной катастрофы? Если да, то является ли это сценарием отката схемы? Используйте сценарий отката для отката базы данных до предыдущей версии кода.

Answer 2

  

Вы должны быть в состоянии создать свою базу данных с нуля до известного состояния.

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

Я определенно интересовался какой-то системой управления версиями БД, но пока ничего не нашел. Так что вместо решения вы получите мой голос. :-P

Answer 3

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

Как и внешние библиотеки , конфигурация базы данных также должна быть в контроль источника.

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

Answer 4

Определите ваши объекты схемы и ваши справочные данные в текстовых файлах с управлением версиями. Например, вы можете определить схему в крутящий момент и данные в формат DBUnit (оба используют XML). Затем вы можете использовать инструменты (мы написали наши собственные) для генерации DDL и DML, которые переносят вас из одной версии вашего приложения в другую. Наш инструмент может принимать в качестве входных данных либо (a) схему предыдущей версии & amp; XML-файлы данных или (b) существующая база данных, поэтому вы всегда можете перевести базу данных любого состояния в правильное состояние.

Answer 5

Мне нравится, как это делает Джанго. Вы строите модели, и когда вы запускаете syncdb, он применяет созданные вами модели. Если вы добавляете модель, вам просто нужно снова запустить syncdb. Это было бы легко, если бы ваш скрипт компоновки выполнялся каждый раз, когда вы нажимали.

Проблема возникает, когда вам нужно изменить уже созданную таблицу. Я не думаю, что syncdb справится с этим. Это потребует, чтобы вы вошли и вручную добавили таблицу, а также добавили свойство в модель. Возможно, вы захотите сделать версию этого утверждения. Модели всегда будут находиться под контролем версий, поэтому, если вам нужно, вы можете получить схему БД и запустить ее на новом компьютере без запуска сценариев sql. Еще одна проблема - отслеживание статических данных, которые вы всегда хотите в БД.

Скрипты Rails-миграции тоже довольно хороши.

Система управления версиями БД была бы великолепна, но я не знаю, что такого.

Answer 6

  

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

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

Answer 7

Поставьте свои разработки базы данных под контроль версий. Я рекомендую взглянуть на дизайнер neXtep: http://www.nextep-softwares.com/wiki

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

В настоящее время он поддерживает Oracle, MySql и PostgreSql. Поддержка DB2 находится в стадии разработки. Это полнофункциональная среда разработки баз данных, в которой вы всегда работаете с элементами управления версиями из репозитория. Вы можете публиковать свои обновления с помощью простой синхронизации во время разработки и создавать экспортные поставки базы данных, которые вы сможете выполнить для любой целевой базы данных с помощью автономного установщика, который проверяет версии, выполняет структурные проверки и применяет сценарии обновления.

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

Всю документацию и концепции можно найти в вики.