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

В вики сообщества SO было некоторое обсуждение того, следует ли управлять версиями объектов базы данных. Однако я не видел особого обсуждения передовых методов создания процесса автоматизации сборки для объектов базы данных.

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

Я хотел бы услышать некоторые идеи от сообщества SO о том, какие практики оказались эффективными в реальном мире.

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

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

1. Следует ли создавать как тестовую, так и производственную среду из системы контроля версий?
   
   • Должны ли оба быть построены с использованием автоматизации - или производство должно быть построено путем копирования объектов из стабильной, завершенной тестовой среды?
   • Как вы справляетесь с потенциальными различиями между тестовой и производственной средами в сценариях развертывания?
   • Как вы проверяете, что сценарии развертывания будут работать в производственной среде так же эффективно, как и при тестировании?
2. Какие типы объектов следует контролировать по версиям?
   • Просто код (процедуры, пакеты, триггеры, Java и т. Д.)?
   • Индексы?
   • Ограничения?
   • Определения таблиц?
   • Сценарии изменения таблицы? (например, сценарии ALTER)
   • Все?
3. Какие типы объектов не должны контролироваться по версиям?
   • Последовательности?
   • Гранты?
   • Учетные записи пользователей?
4. Как следует организовать объекты базы данных в репозитории SCM?
   • Как вы справляетесь с одноразовыми вещами, такими как сценарии преобразования или сценарии ALTER?
   • Как вы справляетесь с удалением объектов из базы данных?
   • Кто должен нести ответственность за продвижение объектов от уровня разработки до уровня тестирования?
   • Как вы координируете изменения от нескольких разработчиков?
   • Как вы справляетесь с ветвлением для объектов базы данных, используемых несколькими системами?
5. Какие исключения, если таковые имеются, можно сделать из этого процесса?
   • Проблемы с безопасностью?
   • Данные, требующие деидентификации?
   • Скрипты, которые нельзя полностью автоматизировать?
6. Как сделать процесс отказоустойчивым и исполнимым?
   • К ошибке разработчика?
   • К неожиданным экологическим проблемам?
   • Для аварийного восстановления?
7. Как убедить лиц, принимающих решения, в том, что преимущества DB-SCM действительно оправдывают затраты?
   • Смехотворное проишествие?
   • Отраслевые исследования?
   • Рекомендации передовой практики отрасли?
   • Обращения к признанным властям?
   • Анализ выгоды и затрат?
8. Кто должен «владеть» объектами базы данных в этой модели?
   • Разработчики?
   • DBA?
   • Аналитики данных?
   • Больше, чем один?

Вот несколько ответов на ваши вопросы:

1. Следует ли создавать как тестовую, так и производственную среду из системы контроля версий? ДА
   • Должны ли оба быть построены с использованием автоматизации - или производство должно быть построено путем копирования объектов из стабильной, завершенной тестовой среды?
   • Автоматика для обоих. НЕ копируйте данные между средами
   • Как вы справляетесь с потенциальными различиями между тестовой и производственной средами в сценариях развертывания?
   • Используйте шаблоны, чтобы на самом деле вы могли создавать разные наборы сценариев для каждой среды (например, ссылки на внешние системы, связанные базы данных и т. Д.)
   • Как вы проверяете, что сценарии развертывания будут работать в производственной среде так же эффективно, как и при тестировании?
   • Вы тестируете их в предпроизводственной среде: тестовое развертывание на точной копии производственной среды (базы данных и, возможно, других систем)
2. Какие типы объектов следует контролировать по версиям?
   • Просто код (процедуры, пакеты, триггеры, Java и т. Д.)?
   • Индексы?
   • Ограничения?
   • Определения таблиц?
   • Сценарии изменения таблицы? (например, сценарии ALTER)
   • Все?
   • Все, и:
     • Не забывайте статические данные (списки поиска и т. Д.), Поэтому вам не нужно копировать ЛЮБЫЕ данные между средами.
     • Сохраняйте только текущую версию скриптов базы данных (конечно, с контролируемой версией) и
     • Храните сценарии ALTER: 1 БОЛЬШОЙ сценарий (или каталог сценариев с именем 001_AlterXXX.sql, так что запуск их в естественном порядке сортировки приведет к обновлению с версии A до версии B)
3. Какие типы объектов не должны контролироваться по версиям?
   • Последовательности?
   • Гранты?
   • Учетные записи пользователей?
   • см. 2. Если ваши пользователи / роли (или технические имена пользователей) в разных средах различаются, вы все равно можете создавать сценарии для них, используя шаблоны (см. 1.)
4. Как следует организовать объекты базы данных в репозитории SCM?
   • Как вы справляетесь с одноразовыми вещами, такими как сценарии преобразования или сценарии ALTER?
   • см. 2.
   • Как вы справляетесь с удалением объектов из базы данных?
   • удален из БД, удален из ствола / подсказки системы управления версиями
   • Кто должен нести ответственность за продвижение объектов от уровня разработки до уровня тестирования?
   • график разработки / тестирования / выпуска
   • Как вы координируете изменения от нескольких разработчиков?
   • старайтесь НЕ создавать отдельную базу данных для каждого разработчика. вы используете систему контроля версий, верно? в этом случае разработчики меняют базу данных и возвращают скрипты. для полной безопасности воссоздайте базу данных из скриптов во время ночной сборки
   • Как вы справляетесь с ветвлением для объектов базы данных, используемых несколькими системами?
   • трудный: постарайтесь избежать любой ценой.
5. Какие исключения, если таковые имеются, можно сделать из этого процесса?
   • Проблемы с безопасностью?
   • не храните пароли для test / prod. вы можете разрешить это для разработчиков, особенно если вы автоматизировали ежедневное / ночное восстановление БД.
   • Данные, требующие деидентификации?
   • Скрипты, которые нельзя полностью автоматизировать?
   • документ и сохранить с информацией о выпуске / скриптом ALTER
6. Как сделать процесс отказоустойчивым и исполнимым?
   • К ошибке разработчика?
   • протестировано с ежедневной сборкой с нуля и сравните результаты с инкрементным обновлением (с версии A на B с помощью ALTER). сравнить полученную схему и статические данные
   • К неожиданным экологическим проблемам?
   • использовать контроль версий и резервное копирование
   • сравните схему базы данных PROD с тем, что вы думаете, особенно перед развертыванием. Администратор баз данных SuperDuperCool мог исправить ошибку, которой никогда не было в вашей системе заявок :)
   • Для аварийного восстановления?
7. Как убедить лиц, принимающих решения, в том, что преимущества DB-SCM действительно оправдывают затраты?
   • Смехотворное проишествие?
   • Отраслевые исследования?
   • Рекомендации передовой практики отрасли?
   • Обращения к признанным властям?
   • Анализ выгоды и затрат?
   • если разработчики и администраторы баз данных согласны, я думаю, вам не нужно никого убеждать (если вам не нужны деньги для покупки программного обеспечения, такого как dbGhost для MSSQL)
8. Кто должен «владеть» объектами базы данных в этой модели?
   • Разработчики?
   • DBA?
   • Аналитики данных?
   • Больше, чем один?
   • Обычно администраторы баз данных утверждают модель (до регистрации или после проверки кода). Они определенно владеют объектами, связанными с производительностью. Но в целом он принадлежит команде [и работодателю, конечно :)]

По возможности я отношусь к SQL как к исходному коду

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

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

1. proj / sql / setup_db.sql
2. proj / sql / dummy_data.sql
3. proj / sql / mssql_specific.sql
4. proj / sql / mysql_specific.sql

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

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

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

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

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

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

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

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

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

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

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

ПО МОЕМУ МНЕНИЮ:

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

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

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

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

• Объекты базы данных всегда может быть восстановлен с нуля, запустив один 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, где схемы также являются пользователями ...

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

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

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

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

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

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

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

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

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

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

См. Хорошее введение здесь:

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

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

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