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

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

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

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

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

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

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

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

Полезны любые истории, прецеденты или даже ссылки.

Ответ 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

Ответ 2

Прочитайте K.Scott Allen для публикаций в версиях баз данных.
Мы создали инструмент для применения сценариев базы данных контролируемым образом на основе тех методов, которые он описывает, и он хорошо работает.
Затем это можно было бы использовать как часть процесса непрерывной интеграции с каждой тестовой базой данных, имеющей изменения, развернутые на нем, когда совершается фиксация URL-адреса, на котором хранятся сценарии обновления базы данных. Я бы предложил иметь базовый сценарий script и сценарии обновления так что вы всегда можете запустить последовательность скриптов, чтобы получить базу данных из текущей версии в новое состояние, которое необходимо.
Это все равно требует от разработчиков каких-либо процессов и дисциплины (все изменения необходимо перевести в новую версию базовой установки script и патч script).

Ответ 3

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

http://www.red-gate.com/products/index.htm

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

Ответ 4

Мы используем модифицированную версию управления версиями базы данных, описанную K. Скотт Аллен. Мы используем Мастер публикации базы данных для создания исходной базовой линии script. Затем пользовательский инструмент С# на основе SMO SQL для удаления хранимых процедур, представлений и пользовательских функций. Сценарии изменений, которые содержат изменения схемы и данных, генерируются с помощью 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 build script каждый раз, когда мы выполняем сборку развертывания через cc.net.

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

Ответ 5

Перейдите сюда:

http://www.codinghorror.com/blog/archives/001050.html

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

Ответ 6

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

Изменить: при использовании технологии Red Gate вы только создаете сценарии, а не обновляете сценарии, так как Red Gate предлагает обновление script. Он также позволит вам отбрасывать и создавать индексы, хранимые процедуры, функции и т.д.

Ответ 7

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

Ответ 8

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

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

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

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

Ответ 9

Гас в одиночку упомянул DB Ghost (см. выше) - я второй как потенциальное решение.

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

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

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

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

Подводя итог:

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

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

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

Ответ 10

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

Наличие одного человека (легендарного администратора базы данных), посвященного задаче управления изменениями в базах данных, в частности производственными базами данных, является очень распространенным решением. Что касается поддержания согласованности между базами разработки и тестирования X: если они/они используются многими пользователями, еще раз вам лучше всего служить, если отдельный акт является "клиринговой палатой" для изменений; если у каждого есть свой собственный экземпляр базы данных, тогда они несут ответственность за поддержание его в порядке, и наличие централизованной базы данных "источник" будет иметь решающее значение, когда им нужна обновленная база данных.

Здесь может быть интересен следующий пост: how-to-refresh-a-test-instance-of-sql-server-with-production-data-without-using

Ответ 11

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

Что касается инструментов, я знаю, что DB Ghost хорошо работает для SQL Server. Я слышал, что версия Data Dude для Visual Studio действительно была включена в последнюю версию, но у меня нет никакого опыта с ней,

Насколько реально вытаскивать разработку баз данных непрерывного интеграционного стиля, он действительно быстро загружает ресурсы из-за количества копий базы данных, которые вам нужны. Это очень удобно, когда база данных может помещаться на рабочей станции разработчика, но непрактична, когда база данных настолько велика, что ее необходимо развернуть по сетке. Для этого вам требуется 1 копия базы данных для каждого разработчика [разработчики, которые делают изменения DDL, а не только изменения в procs) + 6 общих копий. Общие копии:

INT DEV → Разработчики "проверяют" их рефакторинг для INT DEV для тестирования интеграции. Когда тестирование интеграции проходит, эта база данных копируется в DEV.
DEV → Это "официальная" копия разработки базы данных. INT DEV регулярно обновляется с копией DEV. Разработчики, работающие над новыми рефакторингами, получают новую копию базы данных от DEV.
INT QA → Те же идеи, что и INT DEV, за исключением команды QA. Когда здесь проходят интеграционные тесты, эта база данных копируется в QA и DEV *.
ОК
INT PROD → Такая же идея, как INT QA, за исключением производства. Когда здесь проходят интеграционные тесты, эта база данных копируется в PROD, QA * и DEV *
PROD

* При копировании баз данных по линиям DEV/QA/PROD вам также потребуется запустить сценарии для обновления тестовых данных, относящихся к конкретной среде (например, настройка пользователей в QA, которые команда QA использует для тестирования, но которые не существуют в производстве).

Ответ 12

Одним из возможных решений является изучение реализации аудита DML в тестовых базах данных, а затем просто сворачивание этих журналов аудита в script для окончательного тестирования и активного развертывания. SQL Server 2008 значительно улучшает аудит DML, но даже SQL Server 2005 поддерживает его через триггеры.

Ответ 13

В Red Gate есть документ, описывающий, как добиться автоматизации сборки: http://downloads.red-gate.com/HelpPDF/ContinuousIntegrationForDatabasesUsingRedGateSQLTools.pdf

Это построено вокруг SQL Source Control, которое интегрируется с SSMS и существующей системой управления версиями.

Ответ 14

Я написал инструмент, основанный на .NET, для автоматического управления версиями баз данных. Мы используем этот инструмент для производства, чтобы обрабатывать обновления баз (включая патчи) в нескольких средах, вести журнал в каждой базе данных, какие сценарии выполнялись, и делать все это автоматическим способом. Он имеет консоль командной строки, поэтому вы можете создавать пакетные скрипты, которые используют этот инструмент. Проверьте это: https://github.com/bmontgomery/DatabaseVersioning

Ответ 15

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

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

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