Separación de capas y despliegues

Hola,
Otra frase lapidaria en cuanto al uso de capas.
“la separación de capas ayuda en el despliegue de un sistema distribuido, permitiendo que diferentes capas sean situadas de forma flexible en diferentes servidores o clientes, de manera que se minimice el exceso de comunicación y se mejore el rendimiento (Cita de M. Fowler).”
Pasaje de: Architecture, Microsoft. “Guí­a de Arquitectura N-Capas Orientada al Dominio con .NET 4.0.” Krasis Press, 2010-11-29T23:00:00+00:00.
Un saludo.
Miguel.

ASP.NET Merge

Hola,
Alguna vez has necesitado compilar tu proyecto de tipo web site en una dll?
Pues puedes hacerlo mediante la instrucción aspnet_merge lanzado desde la consola de comandos de Visual Studio.
El proceso es sencillo:
1) Precompilar tu sitio web mediante la publicación estándar de un proyecto de tipo web site
2) Una vez precompilado, abrir la consola de comandos de Visual Studio y lanzar la instrucció “aspnet_merge rutaaplicacion -o”
Al entrar en la carpeta bin del sitio que previamente habéis precompilado, veréis que las diferentes dll que habí­a en un inicio se han quedado en solo una.
Aquí­ tenéis la referencia de la MSDN al respecto del comando:
https://msdn.microsoft.com/es-es/library/bb397866%28v=vs.100%29.aspx
Adicionalmente un estupendo video explicativo que describe todo el proceso, y en general el funcionamiento del procesado asociado a la precompilación; muy interesante en general
https://www.asp.net/web-forms/videos/how-do-i/how-do-i-use-the-aspnet_mergeexe-utility-to-merge-assemblies
Un saludo.
Miguel.

Por qué nunca funciona a la primera

Es la pregunta que un compañero de proyecto hací­a durante el despliegue que estuvimos lanzando ayer, después de muchas horas de resolver problemas y situaciones sobre la marcha.
Planificamos bien los tiempos, los documentamos, probamos los procesos y las cargas de datos ante todas las situaciones y contingencias que se nos ocurrieron, pero a pesar de ello, aparecieron situaciones no controladas que tuvimos que ir resolviendo sobre la marcha.
Uno de los problemas fundamentales, la diferencia de entorno, probamos sobre desarrollo, probamos sobre integración, pero no es posible realizar un ensayo general previo sobre producción, y muchas veces, casi todas, las condiciones de dicho entorno cambian, algunas desde el punto de vista de software (eso no deberí­a variar) y otras desde el punto de vista de hardware y comunicaciones (siempre).
Por otro lado, el conjunto de datos, podemos intentar obtenerlos antes del despliegue del entorno de producción y realizar una prueba general sobre ese conjunto de datos en otro entorno, pero normalmente esta combinación no está disponible, ya que el cliente, como es normal, no acepta que sus datos de producción salgan del entorno productivo.
Más situaciones, la participación de terceros, cuando trabajamos con entornos sobre los que no tenemos acceso, terceras personas realizan los pasos del despliegue a partir de la documentación generada por el equipo de proyecto. En Estos casos el error humano se abre camino, tanto en la redacción del documento, en la interpretación por el operador, etc.
Y para mí­ otra de las más importantes, cada despliegue es nuevo, realizando procesos normalmente diferentes, no estamos replicando procesos iguales de forma repetida en el tiempo; no estamos haciendo edificios uno igual que otro una y otra vez, estamos jugando en cada ocasión con N variables que pueden afectar al proceso.
En fin, este trabajo es así­.
Un saludo.
Miguel.

Visual Studio 2008 Web Deployment Project

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

Desplegando Aplicaciones Web ASP.NET con MSI

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.

Desplegando con Integration Services

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.

Despliegues

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.