Repasemos un poco lo que hemos aprendido hasta ahora: sabemos como configurar nuestro Visual Studio On… digo Visual Studio Team Services para crear un Team Project, desarrollar una aplicación en ASP.NET para finalmente compilar y desplegar dicha aplicación cada vez que efectuemos un cambio en el código fuente (Integración Continua).

Todo perfecto, pero recordemos que si queremos definir un conjunto de entornos (QA, DEV, STA, PRO…) entre los que sucesivamente vayamos escalando nuestra aplicación, hacíamos uso de la funcionalidad de Azure llamada “slots”, la cual de una manera sencilla nos permitía intercambiar contenidos entre los diversos entornos, esta técnica es muy practica y nos permite cierto grado de protección a fin de poder revisar nuestros cambios antes de que hagamos el despliegue en el entorno definitivo.

Ahora tenemos una opción adicional, y es que desde la gestión que hace VSTS/TFS manejemos de manera separada la forma en que nuestro “paquete” va siendo desplegado y escalado en los entornos de aprobación hasta su destino “final”: producción, y al hacerlo logramos introducir un factor que sera de gran utilidad de cara al aseguramiento de la calidad de lo entregado: la aprobación de versiones, vale decir que a una persona (o grupo de personas) se le notifica que hay una nueva versión de la aplicación en determinado entorno y que le corresponde dar su conformidad a dicha versión, lo cual derivara en que la versión en cuestión sea propagada al siguiente entorno, y así sucesivamente. Adicionalmente este cambio nos va a permitir manejar ya no solo el historial de nuestras Builds sino tambien el historial de nuestros despliegues, pudiendo ver si todos los despliegues propuestos han pasado los tests de carga y/o fueron aprobados satisfactoriamente por QA o el cliente.

Entonces, debe quedar claro que tenemos que efectuar una revisión al proceso de configuración de la Build Definition que hemos visto anteriormente, y así incorporar el nuevo elemento de la Release Definition, para esto corresponde efectuar las siguientes acciones:

1. Eliminar la etapa de despliegue de la Build Definition
2. Reconfigurar la Build Definition para que el paquete sea generado en una ubicación asequible a todas las etapas, incluyendo la Release
3. Crear una Release Definition y enlazarla con una Build Definition como origen
4. Definir y configurar los entornos de despliegue (para el ejemplo, 2 entornos: QA y PRO)
5. Configuración del aprobador para el pase entre QA y PRO

Por continuidad seguiremos usando el ejemplo de Parts Unlimited que hemos visto hasta el momento.

El paso 1 es simple, y tiene que ver con que en adelante ya no desplegaremos desde la Build, sino desde el Release, para esto nos vamos a Build Definition y hacemos clic en la “x” al lado de la etapa de despliegue:

Antes de proseguir con el paso 2, debemos entenderlo un poco, el mecanismo mediante el cual la Build se comunica con el Release es mediante un archivo .zip (en adelante el “paquete”) el cual debe se configurado para alojarse en una posición asequible tanto para Build como para la Release, y adicionalmente dentro de todas las sub etapas de la Build (como puede ser la ejecución de las pruebas unitarias), esto nos obligara a una revisión de algunos parámetros con los que ya habíamos trabajado anteriormente.

Lo primero que debemos revisar es la tarea llamada Visual Studio Build, debiendo quedar de la siguiente manera:

Y en concreto, el argumento del MSBuild deberia ser el siguiente:

/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.stagingDirectory)"

Ojo al parametro /p:PackageLocation=”$(build.stagingDirectory), pues lo veremos con frecuencia.

Ahora toca ajustar a los tests, concretamente la tarea Visual Studio Test, debiendo quedar de la siguiente forma:

Ahora, si no lo tenemos agregado debemos incluir una tarea Publish Build Artifacts, que servirá de enlace entre la etapa de la Build y la Release Definition que estamos por crear.

Tarea que configuraremos como sigue:

Notese el parametro Copy Root, de esta forma aseguramos la comunicación fluida entre la primera compilación y la generación de los artefactos, de igual manera cabe resaltar que el nombre DemoParts2Builds fue una selección personal para reemplazar al nombre drop que suele aparecer como valor por defecto, pudiendo colocar cualquier nombre, pero asegurándonos de que sea consistente y provea cierta información sobre el contenido que se esta generando.

Hecho esto deberíamos encolar una Build (ya sea manualmente o mediante la publicación de un cambio en el código fuente) y verificar que todos los pasos se completan adecuadamente, como es lógico no se efectuara despliegue alguno puesto que hemos removido dicha tarea de nuestra Build Definition.

El paso 3 ya involucra usar una característica que acaba de ser liberada a preview publica, lo cual implica que ya podemos hacer nuestras pruebas con ella, pero aun no depender de ella para trabajos en “serio”, pero si utilizarla y empezar a configurar nuestros pipelines en ese sentido (pero siempre con un plan de contingencia). Pues bien, para empezar a usar la funcionalidad debemos verificar que en nuestra instancia de VSTS tengamos habilitado el enlace RELEASE, como se ve en la imagen, nótese el * al lado de la opción, esto nos indica su caracter de Preview, verificado esto, nos vamos hacia ese enlace.

Ya en Release, nos toca crear una Release Definition, para lo cual hacemos clic en el “+” en la zona superior izquierda, como se ve en la imagen:

Esto nos deriva con una pantalla donde podremos elegir el tipo de despliegue que vamos a hacer, en este caso elegiremos la opción “Azure Website Deployment” que nos permitirá desplegar a un Azure Web App.

Nos saldrá una pantalla que, debemos reconocerlo, es algo apabullante, así que efectuaremos el primer paso, enlazarnos con los resultados de una Build ya existente:

La siguiente ventana es mucho mas sencilla, pues se nos ofrecerá elegir entre las Build Definitions cuyo ultimo resultado haya sido exitoso, y por defecto estará seleccionada la Build Definition que se haya activado mas recientemente y de paso se nos indica el nombre del artefacto respectivo, en este caso DemoParts2Builds, (Nota adicional: es desde esta pantalla donde podriamos enlazarnos no con el resultado de una BD de VSTS, sino con el resultado de una build generada en… Jenkins!) asi que le damos al botón “Link” para efectuar el enlace respectivo.

Ok, ya hemos enlazado la BD (Build Definition) con la RD (Release Definition)  ahora toca el paso 4, donde configuraremos cada uno de los entornos de despliegue que formaran parte de nuestro pipeline, pero eso sera en el siguiente post, de momento escogeremos un nombre para nuestra RD y grabamos lo avanzado, espero sus comentarios.