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

Я рассматриваю SQL как исходный код, когда это возможно

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

Мы используем непрерывную интеграцию через TeamCity. При каждой регистрации в системе управления версиями база данных и все тестовые данные перестраиваются с нуля, затем код, а затем модульные тесты запускаются с кодом. Если вы используете инструмент генерации кода, такой как CodeSmith, его также можно добавить в процесс сборки, чтобы сгенерировать новый уровень доступа к данным при каждой сборке, убедившись, что все ваши слои «совпадают» и не вызывают ошибок из-за несоответствующие параметры SP или отсутствующие столбцы.

Каждая сборка имеет свой собственный набор сценариев SQL, которые хранятся в каталоге $ project \ SQL \ в системе управления версиями, которым назначается числовой префикс и выполняется по порядку. Таким образом, мы практикуем нашу процедуру развертывания при каждой сборке.

В зависимости от таблицы поиска, большинство наших значений поиска также хранятся в сценариях и выполняются, чтобы убедиться, что данные конфигурации соответствуют нашим ожиданиям, например, «reason_codes» или «country_codes». Таким образом, мы можем изменить данные поиска в dev, протестировать их, а затем «продвинуть» через QA и производство, вместо того, чтобы использовать инструмент для изменения значений поиска в производственной среде, что может быть опасно для времени безотказной работы.

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

Таким образом, мы можем изменить данные поиска в dev, протестировать их, а затем «продвинуть» через QA и производство, вместо того, чтобы использовать инструмент для изменения значений поиска в производственной среде, что может быть опасно для времени безотказной работы.

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

Таким образом, мы можем изменить данные поиска в dev, протестировать их, а затем «продвинуть» через QA и производство, вместо того, чтобы использовать инструмент для изменения значений поиска в производственной среде, что может быть опасно для времени безотказной работы.

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

Задавая «дразнящие вопросы», вы, кажется, больше заинтересованы в обсуждении, чем чье-то мнение об окончательных ответах. Активный (> 2500 участников) список рассылки agileDatabases рассматривает многие из этих вопросов и, по моему опыту, представляет собой сложный и гражданский форум для такого рода обсуждений.

У нас есть наш проект Silverlight с базой данных MSSQL в системе контроля версий Git. Самый простой способ - убедиться, что у вас есть уменьшенная база данных (с точки зрения содержания), и сделать полный дамп из Visual Studio, например. Затем вы можете выполнить sqlcmd из сценария сборки, чтобы воссоздать базу данных на каждой машине разработчика.

Для развертывания это невозможно, так как базы данных слишком велики: это '

I strongly believe that a DB should be part of source control and to a large degree part of the build process. If it is in source control then I have the same coding safe guards when writing a stored procedure in SQL as I do when writing a class in C#. I do this by including a DB scripts directory under my source tree. This script directory doesn't necessarily have one file for one object in the database. That would be a pain in the butt! I develop in my db just a I would in my code project. Then when I am ready to check in I do a diff between the last version of my database and the current one I am working on. I use SQL Compare for this and it generates a script of all the changes. This script is then saved to my db_update directory with a specific naming convention 1234_TasksCompletedInThisIteration where the number is the next number in the set of scripts already there, and the name describes what is being done in this check in. I do this this way because as part of my build process I start with a fresh database that is then built up programatically using the scripts in this directory. I wrote a custom NAnt task that iterates through each script executing its contents on the bare db. Obviously if I need some data to go into the db then I have data insert scripts too. This has many benefits too it. One, all of my stuff is versioned. Two, each build is a fresh build which means that there won't be any sneaky stuff eking its way into my development process (such as dirty data that causes oddities in the system). Three, when a new guy is added to the dev team, they simply need to get latest and their local dev is built for them on the fly. Four, I can run test cases (I didn't call it a "unit test"!) on my database as the state of the database is reset with each build (meaning I can test my repositories without worrying about adding test data to the db).

This is not for everyone.

This is not for every project. I usually work on green field projects which allows me this convenience!

Rather than get into white tower arguments, here's a solution that has worked very well for me on real world problems.

Building a database from scratch can be summarised as managing sql scripts.

DBdeploy is a tool that will check the current state of a database - e.g. what scripts have been previously run against it, what scripts are available to be run and therefore what scripts are needed to be run.

It will then collate all the needed scripts together and run them. It then records which scripts have been run.

It's not the prettiest tool or the most complex - but with careful management it can work very well. It's open source and easily extensible. Once the running of the scripts is handled nicely adding some extra components such as a shell script that checks out the latest scripts and runs dbdeploy against a particular instance is easily achieved.

See a good introduction here:

http://code.google.com/p/dbdeploy/wiki/GettingStarted

Я в основном согласен с каждым ответом, данным ван . Для большего понимания, мой базовый уровень для управления базами данных - K. Серия Скотта Аллена (обязательна к прочтению, ИМХО. И мнение Джеффа тоже кажется).

• Объекты базы данных всегда можно перестроить с нуля, запустив один файл SQL (который сам может вызывать другой Файлы SQL): Create.sql . Это может включать статическую вставку данных (списки ...).
• Скрипты SQL параметризованы так, что никакая зависящая от среды и / или конфиденциальная информация не сохраняется в простых файлах.
• Я использую пользовательский командный файл для запуска Create.sql : Create.cmd . Его цель в основном состоит в том, чтобы проверить предварительные требования (инструменты, переменные среды ...) и отправить параметры в сценарий SQL. Он также может массово загружать статические данные из файлов CSV для устранения проблем с производительностью.
• Обычно учетные данные пользователя системы передаются в качестве параметра в файл Create.cmd .

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

После того, как первая версия базы данных будет запущена в производство, вам понадобятся не только сценарии сборки (в основном для разработчиков), но также и сценарии обновления (основанные на тех же принципах):

• Должен быть способ получить версию из базы данных (я использую хранимую процедуру, но таблица тоже подойдет).
• Перед выпуском новой версии я создаю файл Upgrade.sql (который может вызывать другие), который позволяет обновить версию N-1 до версии N (N является выпускаемой версией). Я храню этот сценарий в папке с именем N-1 .
• У меня есть пакетный файл, выполняющий обновление: Upgrade.cmd . Он может получить текущую версию (CV) базы данных с помощью простого оператора SELECT, запустить сценарий Upgrade.sql , хранящийся в папке CV , и выполнить цикл до тех пор, пока папка не будет найдена. Таким образом, вы можете автоматически обновить, скажем, N-3 до N.

Проблемы с этим:

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

Что касается того, какие объекты базы данных вы хотите иметь под контролем источника? Что ж, я бы сказал как можно больше, но не больше ;-) Если вы хотите создавать пользователей с паролями, получите им пароль по умолчанию (логин / логин, практично для целей модульного тестирования) и сделайте изменение пароля вручную . Это часто случается с Oracle, где схемы также являются пользователями ...

Этот журнал сбрасывается после каждого обновления.

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

Что касается того, какие объекты базы данных вы хотите иметь под контролем источника? Что ж, я бы сказал как можно больше, но не больше ;-) Если вы хотите создавать пользователей с паролями, получите им пароль по умолчанию (логин / логин, практично для целей модульного тестирования) и сделайте изменение пароля вручную . Это часто случается с Oracle, где схемы также являются пользователями ...

Этот журнал сбрасывается после каждого обновления.

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

Что касается того, какие объекты базы данных вы хотите иметь под контролем источника? Что ж, я бы сказал как можно больше, но не больше ;-) Если вы хотите создавать пользователей с паролями, получите им пароль по умолчанию (логин / логин, практично для целей модульного тестирования) и сделайте изменение пароля вручную . Это часто случается с Oracle, где схемы также являются пользователями ...

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

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

Вы можете обнаружить, что Liquibase обрабатывает многое из того, что вы ищете.

Каждый разработчик должен иметь свою собственную локальную базу данных и использовать контроль исходного кода для публикации в команде. Мое решение здесь: http://dbsourcetools.codeplex.com/ Радоваться, веселиться, - Натан

+1 для Liquibase : LiquiBase - это независимая от базы данных библиотека с открытым исходным кодом (LGPL) для отслеживания, управления и применения изменений базы данных. Он построен на простой предпосылке: все изменения базы данных (структура и данные) хранятся в описательной манере на основе XML и регистрируются в системе управления версиями. Хороший момент в том, что изменения DML сохраняются семантически, а не просто diff, так что вы можете отслеживать цель изменений.

Его можно комбинировать с GIT контролем версий для лучшего взаимодействия. Я собираюсь настроить нашу среду dev-prod, чтобы опробовать ее.

Также вы можете использовать системы сборки Maven, Ant для сборки производственного кода из скриптов.

Минус в том, что LiquiBase не интегрируется в широко распространенные IDE SQL, и вам следует выполнять основные операции самостоятельно.

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

IMHO:

1. Храните DML в файлах, чтобы можно было версия их.
2. Автоматизировать процесс построения схемы из контроль версий.
3. В целях тестирования разработчик мог использовать локальную БД, созданную из контроль версий через систему сборки + Данные нагрузочного тестирования со скриптами, или Скрипты DBUnit (из Source Control).
4. LiquiBase позволяет вам выполнять последовательность "сценариев уважать зависимостей.
5. Должна быть команда администраторов баз данных, которая проверяет мастер бранч со ВСЕМИ изменениями перед производственным использованием. Я имею в виду они проверить транк / ветку от других администраторов баз данных перед фиксацией в магистрали МАСТЕР. Чтобы мастер всегда был последовательным и готово к производству.

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