ASP.NET - базовый контрольный список для ввода сайта в производство

Просмотрите свой web.config

Проверить отладку (web.config / * .svc), трассировку, ...

Обновите отладку до производственных значений:

• адрес электронной почты
• адреса (веб) сервисов
• файлы журнала местоположения

быстрый поиск: связь

Также не забудьте проверить настройки gzip в IIS. Сжатие вывода заставит вещи перемещаться по сети намного быстрее.

если это все статическое содержимое, вы захотите использовать агрессивный Кэширование вывода

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

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

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

Если вы просто представляете новости и другие мелочи на сайте компании, которые не так часто меняются, то это решение, вероятно, для вас. Даже если это сайт с гигабайтами данных ... Ключевое слово: как часто мы обновляем данные?

Судя по тому, что я вижу в повседневной работе, никто на самом деле не думает об этом решении, потому что все должно быть «в реальном времени», но есть множество случаев, когда это было бы идеальным решением.

Не выполняйте развертывание по пятницам во второй половине дня! Это гарантированно испортит вам голову на выходные.

У вас должен быть какой-то тест для проверки различных функций вашего сайта и разрешений. Например, после публикации. Просмотрите контрольный список, могу ли я получить доступ к x, если у меня нет разрешения? Работают ли x, y, z в приложении? Я делаю это после каждой публикации, потому что небольшие изменения могут иметь большое влияние.

На самом деле на MSDN есть очень хороший контрольный список по как выполнить проверку развертывания системы безопасности.

Вы должны прочитать это:
https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site

В настоящее время это 9-й вопрос по количеству голосов в SO и входит в тройку самых популярных. Предостережение заключается в том, что он не зависит от платформы, поэтому в нем отсутствуют некоторые элементы, специфичные для ASP.Net.

После очистки кеша браузера тщательно протестируйте сайт за пределами корпоративного брандмауэра / прокси. Это поможет гарантировать, что все ресурсы будут общедоступными (а не на локальном сервере или в кэше). Например, вы можете обнаружить, что использовали абсолютные URL-адреса для включения, скажем, файлов JavaScript или CSS. Они отлично работают в вашей среде разработки, но как только сайт запускается, они становятся недоступными. Или у вас есть файл CSS в вашем кеше, который впоследствии был удален, но вы этого не замечаете.

Убедитесь, что любые используемые вами продукты / приложения, ключи которых привязаны к домену, будут работать на вашем действующем сайте. Сюда входят такие вещи, как ключи Google Map или коммерческие сторонние приложения. Он также включает автоматически генерируемые гиперссылки, рассылаемые, например, в электронных письмах. Вы бы не хотели, чтобы при регистрации пользователя была ссылка на http: //localhost/comfirm.aspx или что-то подобное, не так ли?