Стратегии разработки и развертывания баз данных (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 со следующим журналом:

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

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

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

Запись SQL-инструкций изменений

Основным недостатком поддержания журнала изменений в текстовой форме является отсутствие автоматизации. В идеале реализация изменений базы данных в рабочей базе данных во время развертывания будет так же просто, как нажатие кнопки для выполнения скрипта, а не выполнение списка инструкций вручную. Такая автоматизация возможна путем поддержания журнала изменений, содержащего эти команды 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, подключитесь к рабочей базе данных, откройте окно создания запроса, вставьте содержимое журнала изменений и нажмите кнопку "Выполнить", чтобы запустить скрипт.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Отключение приложения во время развертывания

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

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

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

Сводка

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

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

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

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