Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Pues si, de vuelta… ya tocaba tener algo que compartir con ustedes, y en esta ocasión algo nuevo que sea de utilidad para quienes despliegan sus aplicaciones en servidores, pero… mejor contextualicemos.

Cuando originalmente empece a hacer mis pruebas de despliegue automatizado de aplicaciones en .Net tuve que hacerlo sobre servidores Windows, y para lograr eso se tenia que hacer varios pasos, instalar Web Deploy, asignar usuarios, activar servicios, pre configurar los WebSites o Aplicaciones Web, exportar un perfil, usar ese perfil dentro de la configuración de nuestro despliegue XAML, etc.. de hecho la cosa era tan tediosa que tuve que escribir una documentación de varias paginas para mi antiguo trabajo explicando como se hacia el proceso, y bueno… esa en parte fue la razon por la cual me he enfocado especialmente en lo que es despliegue sobre Web Apps, pero claro siempre me quedo el bichito de como ayudar a optimizar las cosas si la necesidad es trabajar con servidores ya sea IaaS u On Premise.

Así que desde hace unos meses he estado leyendo sobre una nueva funcionalidad que te ofrece VSTS llamada Deployment Groups (ya disponible de manera oficial) que esencialmente permite que tu aplicación se despliegue de manera sencilla hacia un servidor o conjunto de servidores, esto lo logra mediante la ejecución de un script (que ya veremos luego) en la(s) maquina(s) destino que esencialmente instala un agente que facilita la ejecución de los diversos pasos necesarios para la configuración el despliegue de nuestra aplicación, y cuando me refiero a configuración me refiero a que es posible realizar de manera desatendida la creación del Website o Aplicación Web en los servidores destino. Mas aun, esta funcionalidad permite agrupar nuestros servidores de manera lógica, de tal manera que no sea lo mismo desplegar a los servidores de QA que a los de Producción.

Todo bien, así que lo que trataremos ahora es de desplegar nuestra aplicación a un conjunto de Maquinas Virtuales creadas en Azure, las cuales estarán detrás de un balanceador de carga el cual nos proveera de una URL o IP unica, siendo que a la hora de efectuar la petición o request la respuesta podrá provenir de cualquiera de las maquinas virtuales que hayamos desplegado, lo cual facilita mucho la disponibilidad de nuestra aplicación, pero que a la vez proporciona retos respecto al manejo de sesiones y recursos compartidos. Finish Reading: Usando Deployment Groups para facilitar nuestros despliegues sobre servidores (I)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Pues si, como fue prometido, ya va tocando meternos con el modelo de Builds, pero antes de proseguir respondamos la pregunta que deje en el post anterior, ¿en que parte de la solución estoy grabando los parámetros de conexión a la BD? pues en el archivo PartsUnlimitedWebsite.pubxml ya que es ahí donde el wizard de deploy guardo los datos de la cadena de conexión a pesar de que al final no sobrescribió los valores del web.config, nos corresponde editar las secciones de dicho archivo a fin de que no persistan los valores dentro de nuestra solución.

Curiosamente, debemos agregar este archivo a nuestra solución, para lo cual hacemos clic derecho y ya formara parte de lo gestionado por VSO, ojo esto solo funciona si hemos editado adecuadamente nuestro archivo .gitignore como ya hemos explicado en el segundo post de esta serie.

Clipboard27
Bueno, ahora si, subamos el cambio y volvamos a nuestro Team Project en Visual Studio Online, dirigiéndonos a la zona de BUILD, de momento estará vacía.Clipboard28
Posicionados sobre la zona que dice “Build definitions” (nótese que aparte tenemos una zona correspondiente a las XAML definitions) y presionamos el “+”, nos saldrá la siguiente pantalla:Clipboard29
Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

Bueno, luego de una pausa, proseguimos con esta serie de artículos para establecer un escenario completo de despliegue usando el nuevo modelo de Builds que traen tanto Visual Studio Online como Team Foundation Server 2015, ¡así que manos a la obra!

Para proseguir con el demo de Parts Unlimited, debemos mencionar que en este ejemplo se hace uso intensivo de los Resource Groups que ya conversamos anteriormente, esto permite automatizar la creación del entorno donde se desplegara nuestra aplicación, vale decir que reduciremos nuestras visitas al Portal de Azure para la creación de nuestros recursos.

Para facilitar esto debemos preparar a nuestra maquina para que sea capaz de provisionar directamente en Azure, para lo cual abrimos una ventana de PowerShell (con permisos de Administrador, claro esta) y escribimos Set-ExecutionPolicy RemoteSigned.

5554.image_thumb_6CC60E94

Bien, terminaron los preparativos así que ya con la aplicación cargada en Visual Studio (y bien conectada a VSO) vamos al proyecto PartsUnlimitedEnv, hacemos clic derecho y elegimos New Deployment… Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

Quienes han dedicado un rato a ver mi serie sobre automatización en el despliegue de aplicaciones con Azure habrán notado que había varios pasos manuales a la hora de preparar los entornos en los que íbamos a desarrollar y luego desplegar nuestras aplicaciones.

Pero, ¿nos hemos preguntado que pasa cuando hemos llegado a cierta madurez y nos encontramos con un escenario en que?: siempre creamos nuestros Websites en la misma zona geográfica de Azure, el mismo plan de precios, y… que la organización ya definió cuantos slots (ranuras) de despliegue son requeridos para el ciclo de desarrollo antes de que algo pase a producción.

En ese sentido Azure nos ofrece los Azure Resource Manager templates, que nos permiten definir y usar plantillas para automatizar la creación de recursos y entornos completos dentro de Azure, y ojo esto no esta limitado unicamente a Web Apps, sino también a entornos que involucren VM, Docker, Logic App, etc, en suma algo muy potente si queremos simplificar tareas repetitivas.

Este mecanismo llamo mi atención luego de que la genial GiS (a quien pude conocer de pasada en mi época en España) publicara este interesante articulo sobre como crear las citadas plantillas desde Visual Studio y es a ese articulo a donde deben remitirse para entender con detalle las partes de un proyecto de este tipo, luego de lo cual podemos regresar aquí.

¿Ok? En nuestro caso vamos a definir un proyecto de plantilla de tipo Web App (a diferencia de GiS que eligió la Blank Template para explicar con mas detalle la estructura base), así:

RM1En este caso notaremos que a diferencia del ejemplo genérico, lo que obtendremos serán archivos de nombre WebSite.json y WebSite.param.dev.json, los cuales se corresponden con los DeploymentTemplate.json y DeploymentTemplate.param.dev.json que con tanto detalle se describieron en el articulo de GiS.

RM2Ahora lo que haremos sera configurar los diversos archivos a fin de lograr una plantila que automáticamente nos permita:

  • Crear un Web App que incluya dos slots por defecto: “QA” y “Staging
  • Localizar esta Web App (y sus slots) en una zona geografica determinada, en mi caso: “East US
  • Usar siempre un mismo Grupo de Recursos (ya previamente creado en nuestro Portal de Azure, o creado la primera vez que invoquemos la plantilla), en mi caso: “Default-Web-EastUS

Finish Reading: Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue