Prosiguiendo con la entrega anterior, pasamos a los pasos 4 y 5 de este proceso que consiste en configurar cada uno de los entornos de despliegue en los que se va a desplegar la aplicación, la idea que implementaremos en esta ocasión sera la siguiente:

• Cada vez que se efectué un cambio en el código fuente se disparara una Build (Integración Continua, esto ya lo tenemos bien sabido)
• Si la Build es exitosa se disparara una Release
• El primer paso de la Release sera desplegar automáticamente al entorno QA
• Efectuado el despliegue a QA, un aprobador humano dará su conformidad, o no, al contenido desplegado
• Si el despliegue en QA ha sido aprobado, recién entonces se efectuara el despliegue al entorno PRO

Obvio que este esquema puede extenderse para incorporar mas entornos, para añadir pruebas de carga en la nube, distintas categorías entre aprobadores, etc, pero para demostrar el concepto esta prueba sera suficiente.

De momento vamos a identificar correctamente nuestros entornos, así que nos vamos al entorno llamado por defecto «Default Environment» y le cambiamos el nombre…

A QA:

Ya que estamos ahi, aprovecharemos y definiremos los aprobadores de esta etapa, para lo cual hacemos clic en los «…» y elegimos la opción correspondiente del menú desplegable:

Lo cual nos enviara a una pantalla que explicaremos con cuidado…

Como podemos ver, se definen dos tipos de aprobación: una antes del despliegue y otra después del despliegue, la de después del despliegue se entiende por si misma y es lo que hemos explicado anteriormente, se trata de dar validez a lo que se acaba de publicar habilitando el pase del paquete al siguiente entorno; por contra, la aplicación antes del despliegue nos servirá para que alguien nos diga: «Ok, en este momento si seria conveniente actualizar la versión» para de esta manera efectuar el pase en momentos de menor impacto y teniendo todo bajo control, especialmente si hablamos de entornos de Producción.

También podemos ver opciones que nos permiten enviar emails, ya sea al dueño del entorno (en este caso yo mismo, aunque podría agregar otros) cuando se efectuá alguna actividad sobre los entornos (éxito o fracaso de un despliegue), así como a los aprobadores para notificarles que tienen que dar su conformidad a un pase, ya sea antes o después de realizado este.

Como ya indicamos, en este caso me interesa que el pase a QA (primer entorno) se efectué automáticamente luego de realizada la Build, pero que sea necesario una aprobación para efectuar el pase al siguiente entorno (PRO), por lo cual editamos la pantalla para que quede así:

Nótese la importancia de desmarcar la casilla al lado de Automated, solo de esta manera podemos configurar la «necesidad» de una aprobación manual luego del pase, en este caso me he puesto a mi mismo, pero tranquilamente podría haber puesto a cualquiera de los otros usuarios de mi instancia de VSTS.

Aprovecho la ocasión para comentar una peculiaridad muy importante del flujo usando aprobadores en los despliegues, si yo coloco varias personas individuales como aprobadores de un ambiente, esto significara que se requiere el «voto» de todos ellos para dar como bueno el pase, mientras que si colocamos un grupo de usuarios (que hayamos definido en VSTS) bastara con que uno de ellos de el voto para proceder con la aprobación o rechazo del pase. Ojo a este detalle que nos puede ser de gran utilidad a la hora de ir avanzando con procesos mas complejos de aprobación.

Ok, ya tenemos definido al aprobador del entorno QA, ahora lo que haremos sera configurar los datos de conexión al Azure Web App que corresponde en este caso a QA, veamos la imagen, comprobaremos que se parece mucho a algo que ya vimos anteriormente (cuando desplegábamos desde la Build), con dos peculiaridades, uno que la sección Additional Arguments ya nos aparece llenada por defecto a fin de intentar armar una Connection String basándose en parámetros que podemos definir dentro de esta Release Definition, de momento lo dejaremos tal como esta, ya que como no configuraremos dichos parámetros la aplicación tomara los valores que hayamos definido en las propiedades del Azure Web App como vimos anteriormente.

Adicionalmente veremos que en el valor Web Deploy Package figura $(System.DefaultWorkingDirectory)\AzureWebDeploy2\DemoParts2Builds\*.zip y no algo parecido al $(build.stagingDirectory)\*.zip que vimos hace unos posts, en este punto uno se preguntara… ¿y como se sabe el valor que hay que colocar ahí? para esto debemos recordar lo que comentamos en el post anterior respecto a que el enlace mediante la BD y la RD se hace vía los paquetes, los cuales son propagados mediante el paso de la generación de artefactos, y para comprobarlo haremos clic en los «…» (ya que fue así como llene estos valores) al lado de la propiedad Web Deploy Package lo cual nos derivara en la pantalla siguiente:

En este caso he navegado sucesivamente a los niveles mas profundos de la estructura de folders presentada, como puede verse el enlace se hace explicito sobre las ubicaciones de los artefactos que hayamos definido en la Build, nótese ademas la coincidencia con los nombres que definimos anteriormente al crear el artefacto, en este caso le di OK y luego edite manualmente el valor reemplazando el PartsUnlimitedWebsite.zip por un *.zip, con lo que el parámetro Web Deploy Package quedó como ya fue mostrado.

Con esto ya tenemos configurado el entorno QA, ahora lo que haremos crear un entorno llamado PRO, quedando de la siguiente manera:

Y, como es lógico tendremos que configurarlo para que apunte a su entorno destino, quedando de la siguiente manera:

Como se puede ver los datos no difieren mucho de los que definimos para QA, salvo que en este caso el campo Slot esta vació, esto es porque al tratarse de un entorno de «producción» estamos apuntando al site «padre» y no al hijo (slot qa), de igual manera el campo Additional Arguments esta vació, pues, como reitero, la configuración la estamos haciendo dentro del Portal de Azure.

Para cerrar con este entorno PRO hay que indicar que no hemos configurado aprobadores, quiere decir que el despliegue se efectuara inmediatamente después de que se haya aprobado el despliegue efectuado sobre el entorno de QA.

Con los dos entornos configurados toca definir el flujo en su totalidad, para esto nos vamos al enlace Triggers, donde veremos una pantalla como la siguiente:

La explicaremos brevemente, por defecto el check de Continuous deployment esta marcado por defecto, lo cual nos indica que el proceso se disparara cada vez que tengamos una nueva versión del artefacto, luego en el combo «Set trigger…» deberemos precisar (por si no estuviera marcado por defecto) efectivamente cual sera el artefacto «disparador» (nótese que en un entorno en que tengamos diversas BD fácilmente podemos tener varios artefactos); luego debemos prestar atención a los dos cuadros celestes, al estar marcados ambos quiere decir que se efectuara el flujo completo que hemos comentado: despliegue automatico de QA, espera por aprobación de QA para proceder con el despliegue de PRO.

Por contraste si los cuadros estuvieran de la manera siguiente… solo se efectuaría el despliegue a QA:

Y listo, ya hemos configurado la RD, de momento no hemos configurado variables adicionales, ni tampoco los pasos de Test, pero sera suficiente para verificar el concepto, asi que de momento vamos a efectuar la prueba.

Podríamos disparar el proceso de la manera usual: editar el código fuente, hacer un commit y luego esperar a que se complete la Build, pero esta vez haremos algo diferente, trataremos de «redesplegar» alguna build anterior para lo cual regresamos a la pestaña de BUILD, donde veremos el histórico de Builds efectuados sobre esta BD, elegimos una Build que ya tenga unos dias, hacemos clic derecho y elegimos Release como se ve en la imagen:

Nos saldrá un cuadro de dialogo donde se nos pide registrar esta Release «manual» que hemos invocado, asi como definir el entorno destino, esto es porque se trata de un proceso manual y no automático, ofreciendosenos dicha opción.

Pues eso, llenamos los datos como se nos pide, quedando como en la imagen y le damos a Create.

Veremos que dentro de BUILD se nos notifica que esa Build ha sido encolada.

Asi que vamos a la pestaña de RELEASE y vemos que efectivamente el proceso de Release esta en ejecución

Hacemos doble clic y comprobamos el proceso en ejecución:

Regresamos a la lista de Releases, y esperamos unos minutos, veremos que ha cambiado de la siguiente manera:

Esto nos indica que el pase a QA se ha completado y que se requiere que lo de por bueno para continuar con el proceso, volvemos a entrar al detalle:

Luego de revisar los cambios en la web de QA, hacemos clic en ese enlace que esta en la zona amarilla, obtenemos la pantalla de confirmación, agregamos la descripción y aceptamos:

Podemos ver ahora como el estado ha cambiado, lo cual nos indica que ya hemos iniciado el proceso de despliegue a PRO.

Ahora nos toca esperar un poco para que se complete el despliegue, en este caso sera automático como hemos indicado: Para completar este posts analizaremos un poco el historico de releases que he tenido al efectuar este post:

Prestemos atención a la linea del Release-22, en este caso lo que ocurrió, fue que rechace el pase a QA por lo que nunca se hizo el pase a PRO quedando en gris como se ve, por el contrario los Release 18, 15 y 14 si se desplegaron correctamente a QA, pero en ese instante tenia configurado el flujo para que no llegara hasta PRO.

Listo, ya tenemos las bases para poder integrar a Release Management y Visual Studio Team Services en un flujo entero de despliegue que empiece desde la escritura de código, quedo a la espera de sus dudas mientras estudiamos como extender esta potente herramienta.