¿Cúales son las features mínimas para que una Web salga a producción?
Quería hacer un checklist de cuáles son las features mínimas para que una Web salga producción.
Por ejemplo, analizemos la feature: "URL rewriting", como feature si es un requerimiento primordial va de todas maneras. Pero si tu jefe quiere ya la web en producción, y tiene otras features que en las que esta interesado, y dice que por el momento URL rewriting, puede esperar hasta un nuevo release. Yo se cada escenario es único, pero podemos llegar a una aproximación.
-
Seguridad: auntenticación, autiración, permisos, prevención contra ataques, encriptación de información sensible como cadenas de conexión, etc.
-
Manejo de errores: Manejar adecuadamente la presentación de errores al usuario. Por ejemplo: "No se pudo completar la operación debido a: "Object instanced don't exits...".
-
Log de Eventos: Registrar de alguna manera los eventos de la aplicación, y cuando ocurre un problema, saber que paso.
-
Que funcione xD!. No se me ocurre nada más en este momento, pero fácil que me olvido de algo.
Espero su aportes, y recuerden que sea features básicas, con las cuales no se podría salir a producción, o no sería muy adecuado hacerlo.
Sería bonito, decir que un requisito mínimo es que no tenga Bugs o muertitos, pero creo que los muertitos (o bugs) son parte del ciclo de vida del desarrollo de software, y no creo que exista el software perfecto, claro tampoco la aplicación va estar llenas de bugs, y que no funcione nada. Algunas frases irónicas: "Si Microsoft tiene bugs, por que nosotros no
", "Tanto muertito en la aplicación que ya parece cementerio ", "No dejes muchos bugs, los suficientes para estar un par de meses más ".Saludos,
-
Respuestas
A ver si puedo aportar algo...
> Documento de despliegue. En muchos casos son los responsable de TIC los que montan la aplicación, así que este documento se hace indispensable en ese caso.
> Documento de monitorización del servidor. En mi caso el departamento de TIC tiene aplicaciones de monitorización que les sirve para saber si la aplicación funciona correctamente. Yo lo que les paso es lo que tienen que controlar y qué tienen que hacer en caso de error....controlan que los servicios está arrancados, que el IIS está a la escucha, que no haya errores en el EVT etc...Yo les genero un documento con cada release para que ellos puedan realizar la monitorización.
Necesario, necesario no es...pero sí muy útil tener una aplicación de monitorización. Todo depende del tipo de aplicación que estés realizando y la criticidad del servicio que dé.
> Temas relativos a la aplicación
> Asegurarse que la aplicación está en release.....quitar debug=true, trazas...
> Configurar los "CustomError" para evitar que el cliente pueda ver errores.
> Configurarla la sesión adecuadamente. Por ejemplo, si va a estar en una granja de IIS se debería almacenar en una base de datos mejor.
> Si usar el toolkit de ASP.NET Ajax asegúrate que estás usando la dll de release.....lo digo porque a mí me ha pasado de ponerla en debug...:-)
> Encriptar los ficheros de configuración
> En servicios WCF no exportar los metadatos.
> En algunas aplicaciones he optado tb por minimizar algunos js y css porque eran demasido grande...con una herramienta que se llama YUICompressor. Esta operación de compresión la tengo automatizada en mi script de compilación.
> El entorno.
Si estoy montando un entorno, al menos yo me aseguro que el sistema operativo tenga los últimos parches existentes hasta el momento aplicados.
> Securización del entorno....configurar firewall, IIS, autentición etc...desde el punto de vista de seguridad.
Por ejemplo, si la aplicación va en un https, tendrá que tener un certificado válido... Tener en cuenta el principio de mínimo privilegio necesario.
Si se usa una base de datos, el usuario de acceso que tenga los privilegios mínimos requeridos.
> Configuración de IIS....Cosas que puede ser necesario configurar...
Establecer compresión Gzip
Fecha de expiración de las páginas..
La aplicación la establezco en un pool diferente que me creo.
En caso de servicios WCF la extensión .svc no suele venir configurada..
Certificados..
> Pruebas de rendimiento y carga....( esto realmente el algo que debes hacer antes del despliegue )
Sí que veo bastante necesario realizar pruebas de carga para conocer la capacidad que tiene la aplicación y no llevar sorpresas. Yo personalmenta las hago con Team System. Haciendo pruebas de carga y usando el profiler se ven bastante cosillas que mejoran enormemente el rendimiento.
A parte de esto, tb uso dos herramientas Firebug e YSlow. YSlow es una herramiento del grupo de interfaz de usuario de Yahoo que analiza tu Web y te detecta problemas que afectan a la velocidad de carga de las páginas ).
A ver qué os parece..
Todas las respuestas
Pues yo resaltaría las pruebas de carga como muy importante, no es la primera vez que se sube un aplicativo a producción, se conectan 60 o 100 usuarios y aquello empieza a fallar como una escopeta de feria si no es que se cae.
Salu2
- Tienes razon Luis, y de ahi lo único que te queda decir es: pero en mi PC funcionaba...
¿Quién da más?
Saludos, A ver si puedo aportar algo...
> Documento de despliegue. En muchos casos son los responsable de TIC los que montan la aplicación, así que este documento se hace indispensable en ese caso.
> Documento de monitorización del servidor. En mi caso el departamento de TIC tiene aplicaciones de monitorización que les sirve para saber si la aplicación funciona correctamente. Yo lo que les paso es lo que tienen que controlar y qué tienen que hacer en caso de error....controlan que los servicios está arrancados, que el IIS está a la escucha, que no haya errores en el EVT etc...Yo les genero un documento con cada release para que ellos puedan realizar la monitorización.
Necesario, necesario no es...pero sí muy útil tener una aplicación de monitorización. Todo depende del tipo de aplicación que estés realizando y la criticidad del servicio que dé.
> Temas relativos a la aplicación
> Asegurarse que la aplicación está en release.....quitar debug=true, trazas...
> Configurar los "CustomError" para evitar que el cliente pueda ver errores.
> Configurarla la sesión adecuadamente. Por ejemplo, si va a estar en una granja de IIS se debería almacenar en una base de datos mejor.
> Si usar el toolkit de ASP.NET Ajax asegúrate que estás usando la dll de release.....lo digo porque a mí me ha pasado de ponerla en debug...:-)
> Encriptar los ficheros de configuración
> En servicios WCF no exportar los metadatos.
> En algunas aplicaciones he optado tb por minimizar algunos js y css porque eran demasido grande...con una herramienta que se llama YUICompressor. Esta operación de compresión la tengo automatizada en mi script de compilación.
> El entorno.
Si estoy montando un entorno, al menos yo me aseguro que el sistema operativo tenga los últimos parches existentes hasta el momento aplicados.
> Securización del entorno....configurar firewall, IIS, autentición etc...desde el punto de vista de seguridad.
Por ejemplo, si la aplicación va en un https, tendrá que tener un certificado válido... Tener en cuenta el principio de mínimo privilegio necesario.
Si se usa una base de datos, el usuario de acceso que tenga los privilegios mínimos requeridos.
> Configuración de IIS....Cosas que puede ser necesario configurar...
Establecer compresión Gzip
Fecha de expiración de las páginas..
La aplicación la establezco en un pool diferente que me creo.
En caso de servicios WCF la extensión .svc no suele venir configurada..
Certificados..
> Pruebas de rendimiento y carga....( esto realmente el algo que debes hacer antes del despliegue )
Sí que veo bastante necesario realizar pruebas de carga para conocer la capacidad que tiene la aplicación y no llevar sorpresas. Yo personalmenta las hago con Team System. Haciendo pruebas de carga y usando el profiler se ven bastante cosillas que mejoran enormemente el rendimiento.
A parte de esto, tb uso dos herramientas Firebug e YSlow. YSlow es una herramiento del grupo de interfaz de usuario de Yahoo que analiza tu Web y te detecta problemas que afectan a la velocidad de carga de las páginas ).
A ver qué os parece..
Muy completo Ibon
No conocía YSlow, gracias por el aporte
Salu2
Grande Ibon!
El documento de despliegue es básico, incluso si tu mismo vas a montar la aplicación, con este documento un equipo futuro podría también montarla. Y aca podemos incluir algunos puntos de los que has puesto abajo: 1) Pre-Requisitos de la aplicación (si usas ASP.NET AJAX con VS2005, el server tiene que tener instalado ASP.NET AJAX, que el SO tengal los últimos services PACK). 2) Configurar IIS, aca podemos incluir si es necesario crear un application pool, si tenemos que crear un usuario, configurar la seguridad en IIS. 3) Permisos en la base de datos, permisos en las carpetas si vamos a subir archivos. Aunque si haces un instalador, puedes no ser muy detallado aquí, como el instalador de Community Server, el documento más serviría si es que se quiere personalizar alguna de estas configuraciones.
El resto de aportes geniales, y recalcar... recuerda llevarlo todo en modo RELEASE!
Como siempre, genial tu aporte Ibon!
Saludos,
- Como bien dices, el documento de despliegue lo intento hacer siempre y muchos de los temas que comento los incluyo en ese documento.
Queria compartir un link sobre este tema que me parecio muy interesante.
Saludos
Arturo
