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

Ответ 1

Ниже приведены некоторые ответы на ваши вопросы:

• Должны ли быть созданы как тестовые, так и производственные среды из источника управления? Да
  • Должны ли они быть построены с использованием автоматизации - или должны производиться путем создания копий объектов из стабильной, завершенной тестовой среды?
  • Автоматизация для обоих. НЕ копируйте данные между средами
  • Как вы относитесь к потенциальным различиям между тестовыми и производственными средами в сценариях развертывания?
  • Использовать шаблоны, чтобы на самом деле вы могли создавать разные сценарии для каждой среды (например, ссылки на внешние системы, связанные базы данных и т.д.)
  • Как вы проверяете, что сценарии развертывания будут работать так же эффективно, как и при тестировании?
  • Вы тестируете их на предварительной производственной среде: тестовое развертывание на точной копии производственной среды (базы данных и потенциально других систем)
• Какие типы объектов должны контролироваться версиями?
  • Просто код (процедуры, пакеты, триггеры, java и т.д.)?
  • Индексы?
  • Ограничения?
  • Определения таблиц?
  • Сценарии изменения таблицы? (например, скрипты ALTER)
  • Все?
  • Все и.
    • Не забывайте статические данные (списки поиска и т.д.), поэтому вам не нужно копировать любые данные между средами
    • Сохранять только текущую версию сценариев базы данных (конечно, контролируемая версия) и
    • Хранить скрипты ALTER: 1 BIG script (или каталог сценариев с именем понравился 001_AlterXXX.sql, так что их запуск в естественном порядке сортировки будет обновляться с версии A до B)
• Какие типы объектов не должны контролироваться версией?
  • последовательности?
  • Гранты?
  • Учетные записи пользователей?
  • см. 2. Если ваши пользователи/роли (или технические имена пользователей) отличаются между средами, вы все равно можете script их использовать шаблоны (см. 1.)
• Как объекты базы данных должны быть организованы в вашем репозитории SCM?
  • Как вы справляетесь с одноразовыми вещами, такими как скрипты конверсии или скрипты ALTER?
  • см. 2.
  • Как вы относитесь к удалению объектов из базы данных?
  • удалено из базы данных, удалено из соединительной линии/коннектора источника
  • Кто должен отвечать за продвижение объектов от разработки до уровня тестирования?
  • dev/test/release
  • Как вы координируете изменения от нескольких разработчиков?
  • не пытайтесь создать отдельную базу данных для каждого разработчика. вы используете источник-контроль, не так ли? в этом случае разработчики меняют базу данных и регистрируют скрипты. быть полностью безопасным, воссоздать базу данных из сценариев во время ночной сборки
  • Как вы относитесь к ветвлению для объектов базы данных, используемых несколькими системами?
  • жесткий: старайтесь избегать любой ценой.
• Какие исключения, если таковые имеются, могут быть разумными в этом процессе?
  • Проблемы с безопасностью?
  • не хранить пароли для test/prod. вы можете разрешить его для dev, особенно если у вас есть автоматические ежедневные/ночные восстановления БД
  • Данные с проблемами де-идентификации?
  • Скрипты, которые невозможно полностью автоматизировать.
  • документ и сохранить с информацией о выпуске /ALTER script
• Как вы можете сделать процесс упругим и принудительным?
  • К ошибке разработчика?
  • тестируется с ежедневной сборкой с нуля и сравнивает результаты с инкрементным обновлением (от версии A до B с использованием ALTER). сравнить как итоговую схему, так и статические данные
  • К неожиданным экологическим проблемам?
  • использовать управление версиями и резервные копии
  • сравнить схему базы данных PROD с тем, что вы думаете, особенно перед развертыванием. SuperDuperCool DBA, возможно, исправил ошибку, которая никогда не была в вашей системе билета:)
  • Для аварийного восстановления?
• Как вы убеждаете лиц, принимающих решения, что преимущества DB-SCM действительно оправдывают стоимость?
  • Анекдотические доказательства?
  • Отраслевые исследования?
  • Рекомендации по лучшей практике в отрасли?
  • Обращается к признанным властям?
  • Анализ затрат/выгод
  • , если разработчики и администраторы баз данных согласны, вам не нужно никого убеждать, я думаю (если вам не нужны деньги для покупки программного обеспечения, такого как dbGhost для MSSQL)
• Кто должен "владеть" объектами базы данных в этой модели?
  • Разработчики?
  • АБД?
  • Аналитики данных?
  • Более одного?
  • Обычно администраторы баз данных утверждают модель (перед регистрацией или после ее просмотра). У них определенно есть объекты, связанные с производительностью. Но в целом команда владеет им [и работодателем, конечно:]]

Ответ 2

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

Если я могу записать его в стандартном SQL, то он обычно идет в файле в моем исходном элементе управления. Файл будет определять как можно больше, например, SP, инструкции Table CREATE.

Я также включаю фиктивные данные для тестирования в исходном управлении:

• проектируемый /SQL/setup _db.sql
• проектируемый /SQL/dummy _data.sql
• проектируемый /SQL/mssql _specific.sql
• проектируемый /SQL/mysql _specific.sql

И затем я абстрагирую все мои SQL-запросы, чтобы я мог построить весь проект для MySQL, Oracle, MSSQL или чего-то еще.

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

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

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

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

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

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

Ответ 6

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

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

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

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

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

ИМХО:

• Храните DML в файлах, чтобы вы могли версия их.
• Автоматизировать процесс сборки схемы из источника.
• Для целей тестирования разработчик мог использовать локальную БД, созданную из   контроль источника через систему сборки +   нагрузочное тестирование Данные со сценариями или   DBUnit-скрипты (из Source   Control).
• LiquiBase позволяет вам обеспечить "запуск" последовательность "сценариев для уважения   зависимости.
• Должна быть команда DBA, которая проверяет мастер бранч со всеми изменениями   перед тем производство использование. Я имею в виду, они   проверить соединительную линию/ветку от других администраторов баз данных   перед тем как вступить в магистраль MASTER.   Так что мастер всегда согласован   и готовность к производству.

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

Ответ 7

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

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

Ответ 8

Я твердо верю, что БД должна быть частью контроля источника и в значительной степени частью процесса сборки. Если он находится в контроле источника, у меня есть одинаковые защитные меры для кодирования при написании хранимой процедуры в SQL, как и при написании класса на С#. Я делаю это, включая каталог сценариев DB под моим исходным деревом. Этот каталог script не обязательно имеет один файл для одного объекта в базе данных. Это было бы болью в заднице! Я развиваюсь в своем db только в моем проекте кода. Затем, когда я готов зарегистрироваться, я делаю разницу между последней версией моей базы данных и текущей, над которой я работаю. Я использую SQL Compare для этого, и он генерирует script всех изменений. Этот script затем сохраняется в моем каталоге db_update с определенным соглашением об именах 1234_TasksCompletedInThisIteration, где номер является следующим числом в наборе уже существующих скриптов, а имя описывает, что делается при этой проверке. Я делаю это таким образом потому что в рамках моего процесса сборки я начинаю с новой базы данных, которая затем создается программно, используя скрипты в этом каталоге. Я написал пользовательскую задачу NAnt, которая выполняет итерацию через каждый script, выполняющий его содержимое на голом db. Очевидно, что если мне нужны данные для входа в db, то у меня также есть скрипты ввода данных. Это также имеет много преимуществ. Один, все мои вещи версированы. Во-вторых, каждая сборка представляет собой новую сборку, которая означает, что в мой процесс разработки не будет каких-либо скрытых вещей (таких как грязные данные, которые вызывают странности в системе). Три, когда новый парень добавляется в команду разработчиков, им просто нужно получить последнюю информацию, и их локальный разработчик будет создан для них на лету. Четыре, я могу запустить тестовые примеры (я не называл это "unit test"!) В моей базе данных, так как состояние базы данных reset с каждой сборкой (что означает, что я могу протестировать свои репозитории, не беспокоясь о добавлении теста данные в db).

Это не для всех.

Это не для каждого проекта. Я обычно работаю над проектами с зелеными полями, которые позволяют мне это удобство!

Ответ 9

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

Построение базы данных с нуля можно обобщить как управление SQL-скриптами.

DBdeploy - это инструмент, который проверяет текущее состояние базы данных - например, какие сценарии ранее выполнялись против него, какие сценарии доступны для запуска и, следовательно, какие сценарии необходимы для запуска.

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

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

Смотрите хорошее введение здесь:

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

Ответ 10

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

Ответ 11

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