Развертывание изменений веб-сайта ASP.NET И изменений SQL Server без простоев

Question

У меня есть веб-сайт ASP.Net 4.0 с базой данных SQL Server 2008. Я хочу развернуть зависимые изменения как на веб-сайте, так и в базе данных одновременно, сохраняя работоспособность сайта. Моя обычная процедура - сначала развернуть изменения веб-сайта, а во время компиляции веб-сайта развернуть изменения базы данных. Это работает, если я достаточно быстр, чтобы вывести изменения базы данных до того, как первый запрос завершит компиляцию.

Я не хочу никаких простоев на сайте.

РЕДАКТИРОВАТЬ: Я не могу купить новое оборудование или программное обеспечение.

Есть ли лучший способ?

РЕДАКТИРОВАТЬ: Примечание. Мои веб-сайты не используют постоянную информацию, такую ​​как состояние сеанса, поэтому перекомпиляция приложения не вызывает у меня никаких проблем.

Answer 1

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

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

Для ваших изменений в базе данных существуют инструменты, которые могут значительно упростить процесс обновления вашей базы данных.Я бы посоветовал взглянуть на SQL Compare и SQL Data Compare от Red Gate.Эти инструменты позволят вам сравнить схемы и данные и синхронизировать базы данных в считанные секунды.Я использую оба инструмента уже несколько лет, и они действительно экономят время.

SQL Сравнение:

http://www.red -gate.com / products / sql-development / sql-compare /

Сравнение данных SQL:

http://www.red -gate.com / products / sql-development / sql-data-Compare /

Answer 2

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

Пример текущей производственной хранимой процедуры ...

ALTER PROCEDURE [dbo].[p_Stored_Proc_Name]
    @Some_Id INT
AS

Добавление нового параметра в хранимую процедуру ...

ALTER PROCEDURE [dbo].[p_Stored_Proc_Name]
    @Some_Id INT,
    @New_Parameter = 0
AS

Вы должны убедиться, что ваш сохраненный код процедуры обрабатывает @New_Parameter = 0 так, как вы этого хотите.

Answer 3

Насколько ваш код связан с базой данных?В некоторых местах это выглядит так:

dt.Rows[0]["CustomerId"];

ORM отлично подходят для смягчения изменений в базе данных.Тем не менее, это не может быть жизнеспособным вариантом для вас.Вместо этого основных изменений базы данных я бы попытался написать код, который работает с существующей схемой и новой схемой.Например, сделайте ваш код менее зависимым от существующего (или не столбца) столбца ... если не существует для типа int, ноль по умолчанию .... если не существует для varchar, пустой строки по умолчанию.Все проблемы в информатике могут быть решены с помощью другого уровня косвенности ".Батлер Лэмпсон

Answer 4

Мне нравится идея @rick Schott о обратной совместимости изменений в БД. Но, я думаю, вам понадобится какой-то кластер / ферма / сад в конечном итоге. Если у вас есть кластерные веб-серверы и кластерный сервер БД, вы можете взять один веб-сайт и один БД из пула, развернуть их и протестировать приложение там. Затем поместите их обратно в пул, извлеките другие, обновите и верните обратно.

Answer 5

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

Answer 6

Автоматизируйте процесс!

Я бы написал:

1. Скопируйте файл App_Offline.htm на веб-сервер
2. РазвертываниеПриложение ASP.NET
3. Развертывание изменений базы данных (можно запустить параллельно с 2).
4. Удалить или переименовать App_Offline.htm