Стратегии разработки и развертывания баз данных (VB)

Скотт Митчелл

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

Введение

Как обсуждалось в предыдущих руководствах, развертывание приложения ASP.NET влечет за собой копирование соответствующего содержимого из среды разработки в рабочую среду. Развертывание — это не однократное событие, а то, что происходит каждый раз при выпуске новой версии программного обеспечения или при обнаружении и исправлении ошибок или проблем безопасности. При копировании ASP.NET страниц, изображений, файлов JavaScript и других таких файлов в рабочую среду вам не нужно беспокоиться о том, как эти файлы были изменены с момента последнего развертывания. Вы можете слепо скопировать файл в рабочую среду, перезаписав существующее содержимое. К сожалению, эта простота не распространяется на развертывание базы данных.

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

Проблемы развертывания базы данных

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

Между развертываниями базы данных разработки и рабочей базы данных могут быть не синхронизированы. Хотя схема рабочей базы данных остается неизменной, схема базы данных разработки может измениться при добавлении новых функций. Вы можете добавлять или удалять столбцы, таблицы, представления или хранимые процедуры. Также могут быть важные данные, которые добавляются в базу данных разработки. Многие приложения, управляемые данными, содержат таблицы подстановки, заполненные жестко заданными данными, зависящими от конкретного приложения, которые не могут изменяться пользователем. Например, на веб-сайте аукциона может быть раскрывающийся список с вариантами, описывающими состояние выставленного на аукционе товара: New, Like New, Good и Fair. Вместо жесткого программирования этих параметров непосредственно в раскрывающемся списке обычно лучше поместить их в таблицу базы данных. Если во время разработки в таблицу добавляется новое условие с именем Poor, то при развертывании приложения эту же запись необходимо добавить в таблицу подстановки в рабочей базе данных.

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

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

Определение базового плана

Чтобы сохранить изменения в базе данных приложения, необходимо иметь начальное состояние, базовый план, к которому применяются изменения. В одном крайнем случае начальным состоянием может быть пустая база данных без таблиц, представлений или хранимых процедур. Такой базовый план приводит к созданию большого журнала изменений, так как он должен включать создание всех таблиц, представлений и хранимых процедур базы данных, а также любые изменения, внесенные после первоначального развертывания. На другом конце спектра можно задать базовый план в качестве версии базы данных, которая изначально развертывается в рабочей среде. Этот вариант приводит к гораздо меньшему размеру журнала изменений, так как он включает только изменения, внесенные в базу данных после первого развертывания. Это подход, который я предпочитаю. И, конечно, вы можете выбрать более средний подход, определив базовый план как точку между первоначальным созданием базы данных и первым развертыванием базы данных.

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

В вашем распоряжении есть множество средств для создания скрипта SQL базовой версии. В SQL Server Management Studio (SSMS) можно щелкнуть базу данных правой кнопкой мыши, перейти во вложенное меню Задачи и выбрать параметр Создать скрипты. Откроется мастер сценариев, который позволяет создать файл, содержащий команды SQL для создания объектов базы данных. Другой вариант — мастер публикации баз данных, который может создавать команды SQL для создания не только схемы базы данных, но и данных в таблицах базы данных. Мастер публикации баз данных был подробно рассмотрен еще в учебнике Развертывание базы данных . Независимо от того, какое средство вы используете, в конечном итоге у вас должен быть файл скрипта, который можно использовать для повторного создания базовой версии базы данных, если это потребуется.

Документирование изменений базы данных в прозе

Самый простой способ ведения журнала изменений в модели данных на этапе разработки — это запись изменений в прозе. Например, если во время разработки уже развернутого приложения вы добавляете новый столбец в Employees таблицу, удаляете столбец из Orders таблицы и добавляете новую таблицу (ProductCategories), вы будете хранить текстовый файл или документ Microsoft Word со следующим журналом:

Изменить дату	Сведения об изменении
2009-02-03:	Добавлен столбец DepartmentID (int, NOT NULL) в таблицу Employees . Добавлено ограничение внешнего ключа от Departments.DepartmentID до Employees.DepartmentID.
2009-02-05:	Удален столбец TotalWeight из Orders таблицы. Данные, уже захваченные в связанных OrderDetails записях.
2009-02-12:	Создали таблицу ProductCategories . Существует три столбца: ProductCategoryID (int, , IDENTITY), CategoryNameNOT NULL(nvarchar(50), NOT NULL) и Active (bit, NOT NULL). Добавлено ограничение первичного ключа в ProductCategoryID, а значение по умолчанию 1 — .Active

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

Основным преимуществом документирования изменений базы данных в прозе является простота. Вам не нужно знать синтаксис SQL для создания и изменения объектов базы данных. Вместо этого можно записать изменения в прозе и реализовать их с помощью графического пользовательского интерфейса SQL Server Management Studio.

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

Примечание

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

Запись инструкций SQL Change

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

Синтаксис SQL включает ряд инструкций для создания и изменения различных объектов базы данных. Например, инструкция CREATE TABLE при выполнении создает новую таблицу с указанными столбцами и ограничениями. Инструкция ALTER TABLE изменяет существующую таблицу, добавляя, удаляя или изменяя ее столбцы или ограничения. Существуют также инструкции для создания, изменения и удаления индексов, представлений, определяемых пользователем функций, хранимых процедур, триггеров и других объектов базы данных.

Возвращаясь к предыдущему примеру, вы видите, что во время разработки уже развернутого приложения вы добавляете новый столбец в таблицу Employees , удаляете Orders столбец из таблицы и добавляете новую таблицу (ProductCategories). Такие действия приводят к созданию файла журнала изменений со следующими командами SQL:

-- Add the DepartmentID column 

ALTER TABLE [Employees] ADD [DepartmentID] 
int NOT NULL 

-- Add a foreign key constraint between Departments.DepartmentID and Employees.DepartmentID
ALTER TABLE [Employees] ADD 
CONSTRAINT [FK_Departments_DepartmentID]
      FOREIGN 
KEY ([DepartmentID]) 
      REFERENCES 
[Departments] ([DepartmentID]) 

-- Remove TotalWeight column from Orders
ALTER TABLE [Orders] DROP COLUMN 
[TotalWeight] 

-- Create the ProductCategories table

CREATE TABLE [ProductCategories]
(
      [ProductCategoryID] 
int IDENTITY(1,1) NOT NULL,
      [CategoryName] 
nvarchar(50) NOT NULL,
      [Active] 
bit NOT NULL CONSTRAINT [DF_ProductCategories_Active]  DEFAULT 
((1)),
      CONSTRAINT 
[PK_ProductCategories] PRIMARY KEY CLUSTERED ( [ProductCategoryID])
)

Отправка этих изменений в рабочую базу данных во время развертывания выполняется одним щелчком: откройте SQL Server Management Studio, подключитесь к рабочей базе данных, откройте окно Новый запрос, вставьте содержимое журнала изменений и нажмите кнопку Выполнить, чтобы запустить скрипт.

Использование средства сравнения для синхронизации моделей данных

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

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

Существует множество сторонних средств сравнения баз данных, предлагаемых различными поставщиками. Одним из таких примеров является sql Compare от Red Gate Software. Давайте рассмотрим процесс использования sql Compare для сравнения и синхронизации схем баз данных разработки и рабочей базы данных.

Примечание

На момент написания этой статьи текущая версия SQL Compare была версии 7.1, а standard Edition стоила 395 долл. США. Вы можете скачать бесплатную 14-дневную пробную версию.

Когда сравнение SQL запускается, откроется диалоговое окно Проекты сравнения, в котором отображаются сохраненные проекты сравнения SQL. Создайте новый проект. Откроется мастер настройки проекта, который запрашивает сведения о базах данных для сравнения (см. рис. 1). Введите сведения для баз данных среды разработки и рабочей среды.

Рис. 1. Сравнение баз данных разработки и рабочей среды (щелкните, чтобы просмотреть полноразмерное изображение)

Примечание

Если база данных среды разработки является файлом базы данных SQL Express Edition в App_Data папке веб-сайта, необходимо зарегистрировать базу данных на сервере базы данных SQL Server Express, чтобы выбрать ее в диалоговом окне, показанном на рисунке 1. Самый простой способ сделать это — открыть SQL Server Management Studio (SSMS), подключиться к серверу базы данных SQL Server Express и подключить базу данных. Если на компьютере не установлена среда SSMS, вы можете скачать и установить бесплатную SQL Server Management Studio.

Помимо выбора баз данных для сравнения, можно также указать различные параметры сравнения на вкладке Параметры. Один из вариантов, который можно включить, — "Игнорировать имена ограничений и индексов". Напомним, что в предыдущем руководстве мы добавили объекты базы данных служб приложений в базы данных разработки и рабочей среды. Если вы использовали средство для aspnet_regsql.exe создания этих объектов в рабочей базе данных, то вы обнаружите, что имена первичного ключа и уникальных ограничений в разных базах данных разработки и рабочей базы данных различаются. Следовательно, sql Compare помечает все таблицы служб приложений как разные. Можно оставить флажок Ignore constraint and index names (Игнорировать имена ограничений и индексов) и синхронизировать имена ограничений или указать SQL Compare игнорировать эти различия.

После выбора баз данных для сравнения (и просмотра параметров сравнения) нажмите кнопку Сравнить, чтобы начать сравнение. В течение следующих нескольких секунд sql Compare проверяет схемы двух баз данных и создает отчет о том, чем они отличаются. Я намеренно внес некоторые изменения в базу данных разработки, чтобы показать, как такие расхождения отмечаются в интерфейсе СРАВНЕНИЯ SQL. Как показано на рисунке 2, я добавил BirthDate столбец в Authors таблицу, удалил ISBN столбец из Books таблицы и добавил новую таблицу , которая позволяет пользователям, Ratingsпосещающим сайт, оценивать рецензируемые книги.

Примечание

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

Рис. 2. Сравнение SQL Списки различия между базами данных разработки и рабочей базой данных (щелкните, чтобы просмотреть полноразмерное изображение)

Sql Compare разбивает объекты базы данных на группы, быстро показывая, какие объекты существуют в обеих базах данных, но отличаются, какие объекты существуют в одной базе данных, но не в другой, и какие объекты идентичны. Как видите, в обеих базах данных существуют два объекта, но различаются: Authors таблица, к которой был добавлен столбец, и Books таблица, в которой один удален. Существует один объект, который существует только в базе данных разработки, а именно вновь созданная Ratings таблица. Кроме того, в обеих базах данных имеется 117 объектов, которые идентичны.

При выборе объекта базы данных отображается окно Различия SQL, в котором показано, чем отличаются эти объекты. В окне Отличия SQL, которое отображается внизу на рисунке 2, видно, что Authors таблица в базе данных разработки BirthDate содержит столбец, который отсутствует в Authors таблице рабочей базы данных.

После просмотра различий и выбора объектов, которые требуется синхронизировать, необходимо создать команды SQL, необходимые для обновления схемы рабочей базы данных в соответствии с базой данных разработки. Это можно сделать с помощью мастера синхронизации. Мастер синхронизации подтверждает, какие объекты следует синхронизировать, и суммирует план действий (см. рис. 3). Вы можете синхронизировать базы данных немедленно или создать скрипт с командами SQL, которые можно выполнять в свободное время.

Рис. 3. Использование мастера синхронизации для синхронизации схем баз данных (щелкните для просмотра полноразмерного изображения)

Средства сравнения баз данных, такие как Red Gate Software SQL Compare, позволяют легко применить изменения к схеме базы данных разработки к рабочей базе данных так же просто, как наведите указатель мыши.

Примечание

Sql Compare сравнивает и синхронизирует схемы двух баз данных. К сожалению, он не сравнивает и не синхронизирует данные в двух таблицах баз данных. Red Gate Software предлагает продукт sql Data Compare , который сравнивает и синхронизирует данные между двумя базами данных, но это отдельный продукт от СРАВНЕНИЯ SQL и стоит еще 395 долл. США.

Перевод приложения в автономный режим во время развертывания

Как мы видели в этих руководствах, развертывание состоит из нескольких этапов: копирование страниц ASP.NET, master страниц, CSS-файлов, файлов JavaScript, изображений и другого необходимого содержимого из среды разработки в рабочую среду, копирование сведений о конфигурации рабочей среды при необходимости и применение изменений в модели данных с момента последнего развертывания. В зависимости от количества файлов и сложности изменений базы данных выполнение этих действий может занять от нескольких секунд до нескольких минут. В этом окне веб-приложение находится в потоке, и пользователи, посещающие сайт, могут столкнуться с ошибками или непредвиденным поведением.

При развертывании веб-сайта рекомендуется перевести веб-приложение в автономный режим до завершения развертывания. Перевод приложения в автономный режим (и его резервное копирование после завершения процесса развертывания) так же просто, как отправка файла и его удаление. Начиная с ASP.NET 2.0, простое наличие файла с именем app_offline.htm в корневом каталоге приложения переносит весь веб-сайт в автономный режим. На любой запрос к странице ASP.NET на этом сайте автоматически отправляется содержимое app_offline.htm файла. После удаления этого файла приложение вернется в оперативный режим.

Таким образом, вывести приложение в автономный режим во время развертывания так же просто, как отправить app_offline.htm файл в корневой каталог рабочей среды перед началом процесса развертывания, а затем удалить его (или переименовать в другое) после завершения развертывания. Дополнительные сведения об этом методе см. в статье Джона Петерсона о переводе ASP.NET приложения в автономный режим.

Сводка

Задача main при развертывании центров приложений, управляемых данными, вокруг развертывания базы данных. Так как существует две версии базы данных — одна в среде разработки и одна в рабочей среде, эти две схемы баз данных могут стать не синхронизированными по мере добавления новых функций в разработку. Более того, поскольку рабочая база данных заполняется реальными данными от реальных пользователей, вы не можете перезаписать рабочую базу данных измененной базой данных разработки, как это возможно при развертывании файлов, составляющих приложение (ASP.NET страниц, файлов изображений и т. д.). Вместо этого развертывание базы данных влечет за собой реализацию точного набора изменений, внесенных в базу данных разработки в рабочей базе данных с момента последнего развертывания.

В этом руководстве рассматривается три метода ведения и применения журнала изменений базы данных. Самый простой подход — записать изменения в прозе. Хотя эта тактика делает реализацию этих изменений в рабочей базе данных процессом вручную, она не требует знания команд SQL для создания и изменения объектов базы данных. Более сложный подход, который является гораздо более приемлемым в крупных проектах или проектах с несколькими разработчиками, заключается в записи изменений в виде серии команд SQL. Это значительно ускорит развертывание этих изменений в целевой базе данных. Лучшее из обоих подходов можно достичь с помощью средства сравнения баз данных, такого как Red Gate Software SQL Compare.

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

Счастливое программирование!

НазадВперед