Развертывание веб-сайта ASP.NET и обновление базы данных MSSQL с нулевым временем простоя - PullRequest
9 голосов
/ 11 апреля 2011

У меня есть вопрос о веб-сайте ASP.NET и развертывании базы данных MSSQL. Мы размещаем сайт asp.net и разработали новую версию, некоторые файлы asp.net изменены, а база данных немного изменена. Как лучше всего загрузить новую версию веб-сайта и обновить базу данных MSSQL без простоев?

Ответы [ 3 ]

13 голосов
/ 22 апреля 2011

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

Итак, если вы планируете, например, удалить столбец, тоВаше приложение зависит от:

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

Это требует некоторой дисциплины от вашей команды разработчиков, но на удивление легко достичь, если вы правильно настроили среду.(dev / test / staging / production).

Когда вы выпускаете:

  1. Развертывание базы данных изменяется на staging среду, которая так же близка к рабочей, как ивозможный.Делайте это предпочтительно в автоматическом режиме, используя что-то вроде SQL Compare и SQL Data Compare, чтобы вы знали, что база данных полностью соответствует вашей тестовой среде.
  2. Выполните «дымовые тесты», используя old приложения, но новая схема базы данных, гарантирующая, что в базу данных не было внесено никаких существенных изменений.
  3. Освободите код приложения.
  4. Дымовая проверка вашей подготовкиapplication.
  5. Выпуск в производство.

Еще одна вещь, которую мы делаем для обеспечения нулевого времени простоя на сайте, - это сине-зеленое развертывание.Это предполагает наличие 2 папок для каждого веб-сайта, обновление одной и переключение домашнего каталога IIS, когда он обновляется.Я писал об этом здесь: http://davidduffett.net/post/4833657659/blue-green-deployment-to-iis-with-powershell

1 голос
/ 11 апреля 2011

Не для этого.Точка.

Установки с нулевым временем простоя ОЧЕНЬ сложны и включают многоэтапные копии базы данных, предварительно проверяя ее в промежуточной среде, тщательно программируя и повторно синхронизируя базу данных.Всегда лучше взять небольшой перерыв.Спи долго ночью, разверни в 2 часа ночи.Или проснись раньше.Определите, когда аренда неудобна для ваших пользователей.

100% безотказной работы ОЧЕНЬ дорого обходятся с точки зрения количества времени, потраченного на него.Если это не является строгим экономическим обоснованием для этого, случайные простои являются гораздо более разумным деловым решением.

0 голосов
/ 22 апреля 2011

Даже на крупных сайтах, таких как salesforce.com и ebay.com, предусмотрены окна планового обслуживания, в которых хотя бы часть этих сайтов недоступна в течение определенного периода времени из-за изменений в бэкэндах.

Для ebay это каждый четверг nig ht и длится 4 часа, в течение которых "некоторые функции могут быть медленными или недоступными в течение этого времени".Для salesforce они планируют и уведомляют пользователей по мере необходимости.

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

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

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

Пройдя через множество «горячих» производственных процессов, я могу со 100% уверенностью сказать, что ни я, нимои клиенты когда-нибудь хотят иметь дело с этим снова.Абсолютно нет места для ошибки.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...