Con el paso del tiempo y familiaridad nos daremos cuenta que la publicación de un Sitio Web (Web Site) o Aplicación Web (Web Application), es lo más sencillo gracias a la herramienta, es decir, Visual Studio 2005+ o Visual Web Developer Express, sólo hacemos clic derecho sobre el proyecto Web o el Sitio Web, y seleccionamos Copy Web Site o Publish Web Site, y podemos escoger si publicamos directamente hacia un servidor, un FTP, o File System para copiarlo por RED o llevarlo en un USB.
Reducimos el problema, divide y vencerás forever, a llevar los archivos generados a nuestro Servidor Web IIS, que es donde suceden los mayores problemas al publicar un Sitio Web.
Problema Central
En cuanto a la publicación en un Servidor Web, se pondrá más interesante si es que no tenemos acceso remoto al servidor, y sólo podemos copiar los archivos por FTP o subiéndolos vía web, la identificación de problemas será un poco más difícil porque no tenemos acceso a la servidor (verificar permisos en el sistema de archivos, revisar Event Viewer, etc). Por ejemplo, un error en la definición de la de conexión, puede hacer que no podamos acceder a la pagina y confundir sobre el verdadero error, entonces debemos deshabilitar los errores personalizados, en algunos extremos intentar depurar remotamente la aplicación Web (es lo peor que se puede hacer, evitar llevar este tema a los foros). Si una aplicación funciona bien en desarrollo, debería funcionar también en producción sin la necesidad de hacer una depuración remota, sólo es un tema de configuración y permisos.
Alternativa
Una buena práctica si es que recién estamos empezando y el llevar nuestra aplicación a producción se convierte en un grave problema , es tener un página con código “Inline” que sea nuestro robot “buscaerrores”. Cada vez que deseamos publicar una aplicación Web, primero enviaremos a nuestro robot a verificar que la configuración del servidor Web sea el correcta, si el robot pasa la prueba, la publicación del sitio web será una tarea sencilla.
Algunas Ventajas
Ya sea el equipo infraestructura o el equipo de desarrollo, el que realice la publicación de una Aplicación Web, debemos tener un robot que nos permita detectar los siguientes problemas:
- Detectar configuraciones incorrectas en el Application Pool de un Sitio Web. ¿Qué es un Application Pool? Por ejemplo, si no tenemos al usuario por defecto en un Application Pool (NETWORK SERVICE), debemos darle ciertos permisos y hacerlo que pertenezca a un grupo especial para que pueda ser un usuario del Application Pool.
- Verificar que las conexiones a la base de datos funcionen correctamente. Hay muchos sitios web, que no hay ninguna página que no funcione sin hacer conexiones a la base de datos, es decir que si por alguna razón no cambiaron la cadena de conexión al pasar a producción, o el servidor de base de datos no tiene los permisos correctos, ninguna página web de toda la Aplicación va a funcionar. Por ejemplo sitios web que generan sus menús desde la base de datos, este menú estará presente en todas las páginas.
- Verificar que los permisos en el sistema de archivos sea el correcto. Si habilitamos la carga de archivos en nuestra aplicación debemos dar los permisos necesarios al usuario del Application Pool (por defecto NETWORK SERVICE) para que pueda escribir sobre la carpeta donde vamos a poner los archivos.
- Cualquier otra verificación que ustedes requieran hacer antes de pasar una aplicación Web a Producción. La idea es dejar una página base, pero ustedes pueden personalizarla de acuerdo a sus escenarios.
El robot, debe ser muy simple y no depender de ninguna otra página o recurso para funcionar:
Y el código fuente debe ser Inline para que funcione independiente si es un Sitio Web o una Aplicación Web:
Descargar Robot para Verificar IIS para ASP.NET.
Anécdota sobre el tema
Recuerdo hace algunos años, en el team “epica” estábamos liberando una nueva versión de un producto Web para uno de nuestros clientes, el Project Manager tuvo problemas durante la presentación de esta nueva versión, sólo llamo para decirme: “La Web no funciona, revisa que puede estar pasando”. El equipo de infraestructura del cliente (un empresa multinacional) no pudo detectar el problema y sólo se liberaba de la responsabilidad diciendo que la aplicación Web no Funcionaba. Después de un par de intentos fallidos por solucionar el problema, el equipo de desarrollo tuvo que ir a resolver el problema. No recuerdo exactamente el problema, pero era más o menos así: anteriormente habían instalando una Aplicación Web, que había cambiado la estructura común del IIS, ellos al instalar nuestra aplicación Web no lo habían hecho correctamente y nuestra Web estaba heredando el archivo de configuración de la aplicación instalada anteriormente, y por eso no funcionaba correctamente. Después de un par de cambios en el IIS Manager, nuestra aplicación Web estaba funcionando correctamente.
Saludos,