Стратегии развертывания базы данных (SQL Server)

Question

Я ищу способ ежедневного развертывания и поддержания сценариев базы данных в соответствии с выпусками.

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

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

Первая проблема заключается в том, что ни один из сценариев НЕ ДОЛЖЕН быть написан где-либо, обычно все "пытаются" поместить их в папку Subversion, но некоторые из более ленивых людей просто запускают сценарий вживую, и большую часть времени никто не знает кто что сделал с базой данных.

Вторая проблема заключается в том, что у нас есть 4 тестовые базы данных, и они ВСЕГДА находятся вне очереди, и единственный способ действительно их восстановить - выполнить восстановление из действующей базы данных.

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

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

Любые истории, варианты использования или даже ссылки будут полезны.

Answer 1

Для этой самой проблемы я выбрал инструмент миграции: Migratordotnet .

С миграциями (в любом инструменте) у вас есть простой класс, используемый для выполнения ваших изменений и отмены их. Вот пример:

[Migration(62)]
public class _62_add_date_created_column : Migration
{
    public void Up()
    {
       //add it nullable
       Database.AddColumn("Customers", new Column("DateCreated", DateTime) );

       //seed it with data
       Database.Execute("update Customers set DateCreated = getdate()");

       //add not-null constraint
       Database.AddNotNullConstraint("Customers", "DateCreated");
    }

    public void Down()
    {
       Database.RemoveColumn("Customers", "DateCreated");
    }
}

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

Это действительно ценное дополнение к нашей сборке, которое упростило процесс .

Я опубликовал сравнение различных структур миграции в .NET здесь: http://benscheirman.com/2008/06/net-database-migration-tool-roundup

Answer 2

Чтение Серия публикаций К. Скотта Аллена о версиях базы данных .
Мы создали инструмент для контролируемого применения сценариев базы данных на основе описанных им приемов, и он хорошо работает.
Затем его можно использовать как часть процесса непрерывной интеграции, в которой каждая тестовая база данных будет развернута с изменениями, когда выполняется фиксация URL-адреса, в котором хранятся сценарии обновления базы данных. вы всегда можете запустить последовательность сценариев, чтобы перевести базу данных из ее текущей версии в новое необходимое состояние.
Это все еще требует некоторого процесса и дисциплины от разработчиков (все изменения должны быть свернуты в новую версию сценария базовой установки и сценария исправления).

Answer 3

Мы используем SQL Compare от RedGate уже несколько лет:

http://www.red -gate.com / продукты / index.htm

Pro версия имеет интерфейс командной строки, который вы, вероятно, могли бы использовать для настройки процедур развертывания.

Answer 4

Мы используем модифицированную версию управления версиями базы данных, описанную K. Скотт Аллен . Мы используем Мастер публикации баз данных для создания исходного базового сценария. Затем пользовательский инструмент C # на основе SQL SMO для выгрузки хранимых процедур, представлений и пользовательских функций. Сценарии изменений, которые содержат изменения схемы и данных, генерируются инструментами Red Gate . Таким образом, мы получаем структуру типа

Database\
    ObjectScripts\ - contains stored procs, views and user funcs 1-per file
    \baseline.sql - database snapshot which includes tables and data
    \sc.01.00.0001.sql - incremental change scripts
    \sc.01.00.0002.sql
    \sc.01.00.0003.sql

Пользовательский инструмент создает базу данных, если необходимо, применяет baseline.sql, если необходимо, добавляет таблицу SchemaChanges, если необходимо, и применяет сценарии изменения по мере необходимости на основе того, что находится в таблице SchemaChanges. Этот процесс происходит как часть сценария сборки nant каждый раз, когда мы выполняем сборку развертывания через cc.net.

Если кто-то захочет получить исходный код для приложения schemachanger, я могу его выложить на codeplex / google или где угодно.

Answer 5

Если вы говорите о попытке синхронизировать схемы базы данных, попробуйте использовать Red Gate SQL Comparison SDK . Создайте временную базу данных на основе скрипта создания (newDb) - именно так вы хотите, чтобы ваша база данных выглядела. Сравните newDb с вашей старой базой данных (oldDb). Получите набор изменений из этого сравнения и примените его с помощью Red Gate. Вы можете встроить этот процесс обновления в свои тесты, и вы можете попытаться заставить всех разработчиков согласиться с тем, что в одном месте хранится сценарий создания базы данных. Эта же практика хорошо подходит для обновления базы данных в нескольких версиях и запуска сценариев и процессов переноса данных между этапами (с использованием документа XML для сопоставления сценариев создания и переноса данных)

Редактировать: При использовании техники Red Gate вас интересуют только создание сценариев, а не обновление сценариев, поскольку Red Gate предлагает сценарий обновления. Это также позволит вам удалять и создавать индексы, хранимые процедуры, функции и т. Д.

Answer 6

иди сюда:

https://blog.codinghorror.com/get-your-database-under-version-control/

Прокрутите немного вниз к списку из 5 ссылок на сайт odetocode.com. Фантастическая серия из пяти частей. Я бы использовал это в качестве отправной точки для получения идей и определения процесса, который будет работать для вашей команды.

Answer 7

Вы должны рассмотреть возможность использования инструмента сборки, такого как MSBuild или NAnt. Мы используем комбинацию CruiseControl.NET, NAnt и SourceGear Fortress для управления нашими развертываниями, включая объекты SQL. Задача построения NAnt db вызывает sqlcmd.exe для обновления сценариев в наших средах разработки и промежуточных версиях после их проверки в Fortress.

Answer 8

Гас без особого упоминания упомянул DB Ghost (выше) - я рекомендую это как возможное решение.

Краткий обзор того, как моя компания использует DB Ghost:

• После того, как схема для новой БД была разумно определена во время первоначальной разработки, мы используем DB Ghost 'Data and Schema Scripter' для создания файлов сценария (.sql) для всех объектов БД (и любых статических данных), и мы отметьте эти файлы сценариев в системе контроля версий (инструмент разделяет объекты на папки, такие как «Хранимые процедуры», «таблицы» и т. д.). На этом этапе мы можем использовать инструменты DB GHost «Packager» или «Packager Plus» для создания отдельного исполняемого файла для создания новой БД из этих сценариев.
• Все изменения в схеме БД возвращаются в исходный код путем регистрации в определенных файлах сценариев.
• В любое время мы можем использовать упаковщик для создания исполняемого файла, чтобы (а) создать новую БД или (б) обновить существующую БД. Некоторая настройка требуется для определенных зависимых от пути изменений (например, изменений, которые требуют обновления данных), но у нас есть сценарии до обновления и после обновления.

Процесс «обновления» включает создание чистой «исходной» БД, а затем (после предварительного обновления пользовательских сценариев) сравнение между схемами исходной БД и целевой БД. DB Ghost обновляет целевую БД для соответствия

Мы регулярно вносим изменения в производственные БД (у нас 14 клиентов в 7 различных производственных средах), но неизбежно внедряют достаточно большой набор изменений с исполняемым файлом обновления БД Ghost (созданным в процессе сборки). Любые производственные изменения, которые не были возвращены в исходный код (или не были возвращены в соответствующую выпускаемую ветвь), теряются. Это заставило всех последовательно регистрировать изменения.

Подведем итог:

• Если вы применяете политику развертывания всех обновлений БД с использованием исполняемого файла обновления БД Ghost, вы можете «заставить» разработчиков последовательно регистрировать свои изменения, независимо от того, были ли они развернуты вручную в промежуточный период.
• Добавление шага (или шагов) в процесс сборки для создания исполняемого файла обновления DB Ghost фактически выполнит тест, чтобы убедиться, что DB может быть создана из сценариев (т. Е. Потому что DB Ghost создает исходную DB, даже при создании исполняемого пакета обновления) и при добавлении шага (или шагов) для выполнения пакета обновления [на любой из четырех упомянутых вами тестовых БД] вы можете поддерживать свои тестовые БД в соответствии с исходным кодом.

Существуют некоторые оговорки и некоторые ограничения в том, какие изменения «легко» внедрить с помощью этого инструмента (на самом деле это набор связанных инструментов), но все они довольно незначительны (по крайней мере, для моей компании):

• Переименование объектов должно быть выполнено в одном из пользовательских сценариев
• Вся БД всегда обновляется (например, объекты в одной схеме не могут быть обновлены в одиночку), что затрудняет поддержку специфичных для клиента объектов в основной БД приложения

Answer 9

Мы используем Visual Studio для специалистов по базам данных и TFS для управления версиями наших баз данных и управления ими. Это позволяет нам обращаться с нашими базами данных точно так же, как с кодом (извлечение, регистрация, блокировка, просмотр истории версий, ветвление, сборка, развертывание, тестирование и т. Д.), И даже включать их в те же файлы решения, если мы хотим.

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

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

Это отличный продукт, но его внедрение было затруднено на раннем этапе из-за ошибки Microsoft в маркетинге. Первоначально это был отдельный продукт под Team System. Это означало, что для одновременного использования функций редакции разработчика и базы данных необходимо было перейти на гораздо более дорогую редакцию Team Suite. Мы (и многие другие клиенты) выразили сожаление по этому поводу Microsoft, и мы были очень рады, что в этом году они объявили, что DB Pro свернут в версию для разработчиков , и что тот, кто имеет лицензию для разработчиков, сразу же может установить издание базы данных.

Answer 10

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

Добавьте таблицу с именем 'DB_VERSION' или аналогичную. В КАЖДОМ сценарии обновления добавьте в эту таблицу строку, которая может включать столько столбцов, сколько вы считаете нужным для описания обновления, но как минимум я бы предложил {VERSION, EXECUTION_DATE, DESCRIPTION, EXECUTION_USER}. Теперь у вас есть конкретная запись того, что происходит. Если кто-то запускает свой собственный неавторизованный скрипт, вам все равно придется следовать советам из приведенных выше ответов, но это всего лишь простой способ кардинально улучшить существующий контроль версий (т. Е. Нет).

Теперь у вас есть сценарий обновления базы данных с v2.1 до v2.2, и вы хотите проверить, действительно ли парень-одиночка действительно запустил его в своей базе данных, вы можете просто искать строки, где VERSION = 'v2. 2 ', и если вы получите результат, не запускайте этот скрипт обновления. При необходимости может быть встроен в консольное служебное приложение.