ASP.NET - Lista de comprobación básica para poner un sitio en producción

Question

Estoy construyendo un sitio estático de ASP.NET (usando páginas maestras y algunas formas) y estoy a punto de lanzarlo a mi servidor de producción.

Sé acerca de cómo cambiar <compilation debug="true"> a falso, pero me pregunto qué otras cosas puedo hacer para obtener la mayor velocidad posible. No hay acceso a datos en el sitio, todo es contenido estático.

¿Alguien tiene una lista de verificación que se ejecuta o sabe de un buen recurso para configurar sitios en un entorno de producción, con un enfoque en el rendimiento?

Lista de comprobación hasta ahora (dude en para corregir esto por sí mismo con las adiciones por valor)

1. Asegúrese <compilation debug="false" /> el valor definido para falsa en Web.Config
2. Asegúrese <trace enabled="false" /> se establece en realidad a falso en Web.Config
3. Establecer los permisos necesarios para leer/escribir/modificar carpeta para el sitio
4. Habilite GZIP en IIS (reduce el tamaño de páginas/css/javascript de forma espectacular)
5. ¿Ha considerado OutputCaching para cualquier página/control?
6. Considere la posibilidad de configurar pruebas web (por ejemplo, WatiN para .NET) para asegurarse de que la funcionalidad en su sitio aún funciona bien
7. ¡Asegúrese de que no sea viernes por la tarde!

Answer 1

revisión de su web.config

Registro de depuración (web.config/* .svc), la localización, ...

actualización de depuración de los valores de producción:

• direcciones de correo electrónico
• (web) direcciones de servicio
• archivos de registro de ubicación

búsqueda rápida: link

Answer 2

Además, no se olvide de comprobar la configuración de GZIP en IIS. La compresión de la salida hará que las cosas viajen a través del cable mucho más rápido.

Answer 3

si su todo el contenido estático, tendrá que utilizar agresiva Output Caching

Answer 4

Si va a escribir los archivos de registro o de salida, asegurarse de que los permisos de las carpetas adecuadas están configurados en el entorno de producción. Normalmente, los entornos de depuración/prueba son mucho más flexibles en los permisos de lectura/escritura de archivos que en la producción.

Answer 5

Si su sitio utiliza una base de datos y solo presentando información, haga que la base de datos sea de solo lectura. Eso le quita todo el manejo de bloqueo y acelera el acceso a una gran oferta de .

Si tiene un back-end que actualiza los datos, conviértalo en una base de datos separada y programe períodos que actualicen la base de datos de solo lectura una vez al día o lo que se necesita para esa aplicación.

Si solo presenta noticias y otras cosas pequeñas en el sitio web de una empresa que no cambian con tanta frecuencia, entonces esta solución es probablemente para usted. Incluso si es un sitio con gigabytes de datos ... La palabra clave es, ¿con qué frecuencia actualizamos los datos?

Por lo que veo en los negocios diarios, nadie realmente piensa en esta solución porque todo tiene que ser "en tiempo real", pero hay muchos casos en que esta sería una solución perfecta.

Answer 6

¡No se despliegue los viernes por la tarde! Esto está garantizado para arruinar tu cabeza durante el fin de semana.

Answer 7

Debe tener algún tipo de prueba para verificar las diversas funciones de su sitio y los permisos. Por ejemplo, una vez que publicas. Repase una lista de verificación. ¿Puedo acceder a x si no tengo permiso? ¿Funcionan x, y, z en la aplicación? Lo hago después de cada publicación porque los pequeños cambios pueden tener un gran impacto.

Answer 8

En realidad, hay una muy buena lista de comprobación en how to perform a security deployment review proporcionada en MSDN.

Answer 9

Usted debe leer esto:
https://stackoverflow.com/questions/72394/what-should-a-developer-know-before-building-a-public-web-site

Es actualmente el noveno con más votos pregunta en PC y en la parte superior 3 Más Favorecido. La advertencia es que es independiente de la plataforma, por lo que le faltan algunos elementos específicos de ASP.Net.

Answer 10

Pruebe a fondo el sitio fuera de su firewall/proxy corporativo después de borrar la caché de su navegador. Esto ayudará a garantizar que todos los recursos sean de acceso público (y que no estén en un servidor local ni en caché). Por ejemplo, puede encontrar que ha utilizado URL absolutas para incluir, por ejemplo, archivos JavaScript o CSS. Funcionan bien en su entorno de desarrollo, pero tan pronto como se lanza el sitio, son inaccesibles. O tiene un archivo CSS en su caché que posteriormente se ha eliminado, pero no se da cuenta.

Asegúrese de que cualquier producto/aplicación que use que tenga claves que estén vinculadas a un dominio funcionará en su sitio en vivo. Esto incluye cosas como Google Map keys o aplicaciones comerciales de terceros. También incluye hipervínculos generados automáticamente enviados, por ejemplo, en correos electrónicos. No querría que el registro de un usuario tuviera un enlace de regreso al http://localhost/comfirm.aspx o similar, ¿verdad?