05.22.09
Posted in Despliegues, Herramientas at 5:51 pm by Miguel
Una de las características de los proyectos de tipo “Sitio Web” de Visual Studio 2008 es que permite la pre-compilación de la web mediante una serie de características más avanzadas de las que provee un proyecto web.
Por ejemplo, permite hacer cosas como generar una dll por cada una de las carpetas de la aplicación o incluso generar una dll independiente por cada página y control de usuario. Dependiendo un poco de las necesidades que tengáis para vuestros despliegues os puede resultar interesante utilizar una de las combinaciones que la pre-compilación ofrece. Teniendo en cuenta que además lograréis algunas características avanzadas en el despliegue como son:
1) Mejor respuesta ante las peticiones web. No tiene mucho misterio, si habéis precompilado antes, cuando el IIS reciba la petición no necesitará compilar la página solicitada para mostrarla al usuario, por lo que los tiempos de respuesta serán mejores.
2) Nivel de seguridad. Precompilando estáis ocultando el contenido de vuestros archivos Code-Behind, por lo que nadie podría conocer cómo está funcionando vuestra aplicación por dentro y/o modificar el funcionamiento de la misma.
3) Mayor flexibilidad en el despliegue. Con las diferentes combinaciones de publicación que permiten o generar dll por carpeta o por página y control, podéis lanzar actualizaciones de vuestros sitios web sin necesidad de desplegarlos enteros nuevamente, si no sólo las dll correspondientes a las páginas o controles que habéis modificado (esto les gusta mucho normalemente a los departamentos de sistemas encargados de realizar los despliegues).
Además, otra capacidad muy interesante se nos ofrece con la pre-compilacion, que es el no permitir que el sitio sea actualizable (allow this precompiled site to be updatable). Si marcais esta opción no se va a dejar modificar el código de presentación asociado a aspx y ascx. Es más, veréis incluso que los archivos ascx no se han generado, y que los aspx sí que están pero si los abrís únicamente veréis que guardan en su interior una referencia a la dll que los representa. Esta solución es fantástica si lo que queréis es evitar a toda costa cualquier modificación también en la capa de presentación.
Pero después de todo esto, algo se nos queda en el tintero, y es la posibilidad de poder asociar el resultado de la precompilación directamente a un proyecto de tipo Web Setup. Para ello disponemos de la herramienta Web Deployment Project (plugin para Visual Studio), que nos aportará las facilidades que ya hemos tratado más esta última. Es tan sencillo como lanzar el build del sitio web, a continuación lanzar el build del Web Deployment Project asociado al sitio web, relacionar el output del proyecto de deployment al proyecto de web setup, compilar el setup, y óle, ya tenemos un msi con el contenido pre-compilado de nuestra web siguiendo uno de los métodos estándar que hayamos elegido.
Os dejo un pequeño manual bastante claro de uso para la versión de Web Deployment Project para Visual Studio 2005. El único problema es que aquí no se explican nuevas capacidades de la versión 2008 como la de lanzar el deploy directamente sobre un site de IIS, pero de todas maneras dejo el link al manual porque a pesar de todo se describe muy claramente los pasos a seguir.
Link a manual Web Deployment Project para Visual Studio 2005
Descargar Web Deployment Project para Visual Studio 2008
Permalink
04.20.08
Posted in .NET, Despliegues at 11:36 pm by Miguel
Desde hace tiempo quería preparar un artículo donde se describiera cómo desplegar aplicaciones web ASP.NET mediante archivos MSI. La utilizacion de los MSI resulta en una solución que aumenta la calidad de los despliegues y minimiza la tasa de errores en el proceso.
Es curioso pero ya muchos desarrolladores toman como común y obvio la existencia de aplicaciones que preparan ejecutables para aplicaciones de escritorio, pero no parece que ocurra lo mismo con los despliegues de aplicaciones web, donde no se tiene constancia de que también es posible hacer lo mismo.
En concreto, desde la versión 2005 de Visual Studio se incorpora dicha posibilidad, que brinda toda la potencia que os quería presentar aquí mismo, pero visto lo visto, tras encontrar el link que abajo os expongo, me parece a mi que no hay mucho más que decir, por lo que me limito a dejároslo para que lo estudieis a fondo. La verdad es que es un artículo magnífico.
Artículo
Saludos.
Miguel.
Permalink
02.27.08
Posted in Despliegues at 1:19 pm by Miguel
Para los que tengáis experiencia desplegando aplicaciones o actualizaciones de las mismas en cliente, tendréis más que vista la problemática que supone el despliegue de los scripts con las actualizaciones de la base de datos. Dependiendo del tamaño del despliegue os podéis plantar con un script para lanzar o con decenas o cientos de ellos, y cuantos más tengamos, más aumenta la probabilidad de que ocurra un error.
Los scripts de actualización de base de datos tienen varios problemas principales:
1) Deben lanzarse en el orden correcto. Por ejemplo, como se os ocurra hacer una modificación de una tabla que aún no habéis creado, fallará.
2) Como te dejes un script por pasar, no te vas a enterar seguramente hasta que la aplicación intente actualizar una tabla, o un campo que supuestamente debería existir.
3) Si lanzas el script en la base de datos que no toca, puede que no de error, pero cuando la aplicación se ejecute sobre la base de datos va a darte el mismo problema que en el punto 2.
4) Normalmente los scripts de actualización no los vas a lanzar tú, si no una tercera persona, por lo que al no tener control sobre ello debes dar por hecho que el error puede ocurrir… y si puede ocurrir… ocurrirá.
5) En caso de error o de querer retornar al estado anterior, deberás tener preparados los scripts de vuelta atrás (también se les llama contramedidas). Lanzando los scripts de vuelta atrás puedes tener los mismos problemas que los puntos 1, 2, 3 y 4.
Y ahora la pregunta del millón, ¿hay alguna forma de minimizar estos riesgos? Afortunadamente sí.
No sé si conocéis Integration Services, es una de las herramientas de integración de datos que provee SQL Server 2005. Sirve para muchas cosas, mantenimiento de bases de datos, creación de ETL’s, y mira tú por donde, podemos usar su potencia para desplegar scripts para el cliente.
Una de las principales ventajas de Integration es que funciona como un motor de flujo, donde nosotros vamos indicando el inicio del flujo, las actividades que forman parte de él y la forma en la que se relacionan.
Únicamente ya al tratarse como un motor de flujo tenemos resuelto uno de los principales problemas, la secuencialidad. Seguro que se ejecutan los scripts en el orden correcto ya que de eso se va a encargar el motor de flujo (si es que hemos definido bien el flujo claro).
Otro de los grandes problemas que se solucionan es que a la hora de que lance la actualización esa tercera persona, seguro que va a lanzar lo mismo exactamente que has probado tú, ya que va a lanzar un paquete entero que internamente va a lanzar los scripts para los que haya sido preparado. Este mismo problema se soluciona en el caso de querer lanzar los scripts de vuelta atrás.
Eso sí, el tema de dejarte un script sin definir eso no lo resuelve nadie. Si en desarrollo modificaste una tabla y no dejaste constancia en ningún lado, cuando hagas el paquete de integration no reflejarás el cambio, por lo que la base de datos de producción no estará en consonancia con la tuya, y, entonces, fallará.
Finalmente otros temas a discutir aquí que suponen mejoras añadidas, valores no tangibles, son los siguientes:
1) Es mucho más fácil de mantener y desarrollar un paquete de integration que un archivo sql con 800 scripts sueltos dentro.
2) El minimizar los problemas en el despliegue aumenta la calidad de tu producto.
3) Tu imagen cara al cliente se ve mejorada, no es lo mismo entregar 20 scripts que un paquete de integration. Lo segundo da una imagen más profesional y controlada.
Saludos.
Miguel.
Permalink
02.25.08
Posted in Despliegues at 9:21 pm by Miguel
Hoy en el blog abrimos otra lata más, en lo que será un conjunto de posts al respecto de los despliegues de aplicaciones.
No vamos a aprender a desplegar aplicaciones de una tecnología en concreto, si no que se va a tener en cuenta otros principios básicos sobre los despliegues, ideas de cómo enfocarlos, como ejecutarlos, cómo organizar los documentos de despliegue, y otras ideas de cómo conseguir minimizar los tiempos, aumentar la calidad, etc.
Como aperitivo respecto a este tema, me gustaría dejar algunas reflexiones al respecto:
1) Tal vez tu cliente no vea nunca una línea de tu código, pero seguro que se lee el documento de despliegue, y además, será la primera toma de contacto real con tu producto.
2) Los despliegues también se tienen que probar. Probar un despliegue en un entorno que no tiene que ver con el real no te va a servir de nada.
3) Ten en cuenta que el departamento de sistemas de tu cliente va a querer tener muy claro qué es lo que vas a desplegar. El despliegue no sólo afectará al departamento de desarrollo.
4) Las diferentes tecnologías de desarrollo disponen de productos que ayudan a preparar despliegues, tal vez debas dedicar algo de tiempo a investigar al respecto.
5) Cada uno de tus despliegues no es algo independiente en la vida de tu producto. Podrás aplicar la reutilización, la mantenibilidad y el aumento de valor también en tus despliegues. Aprende de tus despliegues y aumenta tu conocimiento.
6) Es una pena que con el trabajo que te ha llevado que tu aplicación funcione en las máquinas de desarrollo, no funcione en pre-producción porque no has sido capaz de definir bien el despliegue. Si no funciona en pre-producción tu trabajo no vale para nada.
7) Si tras el despliegue no eres capaz de retornar la aplicación a su estado inicial, la llevas clara.
Saludos.
Miguel.
Permalink