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

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

1. проектируемый / SQL / setup_db.sql
2. проектируемый / SQL / dummy_data.sql
3. проектируемый / SQL / mssql_specific.sql
4. проектируемый / SQL / mysql_specific.sql

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

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

Answer 3

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

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

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

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

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

ИМХО:

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

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

Answer 4

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

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

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

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

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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

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

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

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

Answer 8

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

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

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

Answer 9

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

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

Answer 10

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