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.

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.
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:
Como es lógico, por el tipo de proyecto que estamos trabajando, elegimos un proyecto de Visual Studio, como podemos ver en la zona izquierda esta Build Definition ya cuenta con cuatro pasos: La Build en si misma, la ejecución de Tests, la publicación de símbolos y la publicación de los artefactos de la Build.
Antes de configurar las partes de nuestro flujo, debemos configurar algunos parámetros globales, en este sentido elegimos el repositorio de Git sobre el que vamos a trabajar (nótese que en esta etapa podríamos enlazarnos a un proyecto en GitHub) y algo muy importante elegir la rama/branch respectiva, en esta etapa por simplicidad elegimos “Clean” como falso para que de esta manera en los despliegues sucesivos solo suba lo diferencial.
Ok, ahora configuremos los pasos de nuestra nueva Build Definition, así que vamos al primer paso “Visual Studio Build” y procedemos a buscar el .sln respectivo marcando los “…” que vemos resaltados en el gráfico.
Aquí se nos ofrecerá la opción para ubicar la solución respectiva que ya ha sido subido al repositorio Git.
Ya con esta selección nos corresponde parametrizar nuestra build, para lo cual en MSBuild Arguments agregamos esto:

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

Con esto le indicamos a MSBuild que empaquete el resultado de la Build y donde alojara dicho paquete, esto será importante al momento del despliegue en si.

Le damos a grabar y de paso le asignamos un nombre, en este caso ConsultorInternetPUBuild1:
Ahora debemos configurar bajo que condiciones se disparara nuestra Build, vamos a la pestaña de Triggers, elegimos  y ahí nos aseguramos de que estamos incluyendo al branch correcto, en este caso “milocal2”. Un detalle importante es que aquí podemos apreciar una de las ventajas del nuevo modelo de Builds: tradicionalmente si quería que se ejecutara una Build tanto al actualizar  el código fuente (Integración Continua) como de manera programada (medianoche, cada cuatro horas, etc) tenia que crear varias Build Definition, como podemos ver eso ya no es necesario, nos basta con hacer check a las opciones correspondientes.
Bueno, nuestra Build Definition esta lista, ahora modificamos una vista de Home, agregando un texto que nos servirá para ver que las cosas están funcionando.
Luego de la modificación subimos los cambios (Commit) y veremos que tenemos una nueva Build encolada, esperando iniciar su ejecución.
Unos minutos mas tarde, podemos ver que esta Build se ha completado, nótese que ahora tenemos a nuestra disposición la descarga de TODOS los logs del proceso, algo nuevo con esta versión.

Llegados a este punto, debo decirles que solo hemos probado que nuestro proyecto compila (y/o las pruebas no se caen, si las tuviéramos) , pero aun no se ha desplegado, esto es porque NO hemos agregado a nuestra Build Definition el paso que logra desplegar un proyecto Web a un Azure Web App, así que no queda sino agregar el paso respectivo eligiéndolo de dentro la galería de pasos que nos ofrece VSO.
Como primer paso, debemos vincular nuestra Build Definition a la Azure Web App que ya tenemos creada, pero mas aun… debemos enlazar nuestro Team Project con nuestra subscripción a Azure, de ahí que nomas agregar el paso a nuestra BD se nos resalta en rojo ese importante detalle, así que hagamos clic en Manage, como se ve en el grafico.
Esto nos abrirá una nueva pestaña del navegador donde tendremos la opción de agregar lo que se han denominado “Service Endpoints” y como es lógico el Service Endpoint a agregar es Azure.
Aquí nos corresponder agregar los detalles de nuestra subscripción a fin de establecer el enlace.
Con esto ya no tendremos la alerta en rojo, ahora deberemos seleccionar el nombre de la Web App (de momento debemos escribirlo a mano pues el combo aun no carga los valores) así como su ubicación y en el campo Web Deploy Package deberemos agregar el valor $(build.stagingDirectory)\*.zip que permitirá que el paso de despliegue pueda ubicar el package generado en el primer paso.
Listo, ya esta la Build Definition, y como ya habíamos subido un cambio, no vamos a subir otro sino simplemente encolar manualmente  una nueva Build haciendo clic en el enlace “Queue build…”
Luego de dar clic en OK veremos el proceso de encolamiento, y como es lógico, apreciaremos en el log que se ha ejecutado el nuevo paso de despliegue.
Vamos a la web y vemos que figura el texto en cuestión.

Ok, la aplicación esta arriba y nuestra Build esta desplegando, pero debemos ser conscientes de que hemos desplegado directamente en un entorno de Producción, lo cual no es buena practica bajo ningún punto de vista, por lo que seria muy conveniente crear entornos previos de despliegue (como mecanismo de prueba antes del pase a producción), para lo cual aplicaremos los conceptos de slots/ranuras que ya hemos aprendido en un post anterior, y seguidamente nos valdremos de otra nueva característica de TFS/VSO que nos permite especificar el slot en que se desplegara la aplicación, en nuestro caso he creado un slot llamado “qa” y ese será el que configuremos.

Listo, ya tenemos separado el entorno de qa y el de producción siendo que nuestros despliegues se están efectuando hacia “qa” para luego mediante un “swap” poder hacer el intercambio respectivo, nótese además que hemos configurado nuestro slot “qa” para que maneje sus cadenas de conexión (como vimos en el articulo anterior)  independientemente del slot principal.

Claro que para hacer eso uno debe efectuar la copia respectiva de la BD entonces en producción, o simplemente crear una en blanco y dejar que las Migrations de Entity Framework se hagan cargo de llenar la BD con contenido, en todo caso no queda sino recalcar que estamos logrando que tanto QA como producción tengan sus propias cadenas de conexión y que estas no sean gestionadas desde el código fuente de nuestro proyecto en VS.

Queda como tarea revisar el proyecto de Parts Unlimited y ver como el template FullEnvironment de Azure Resource Manager se hace cargo de la tarea de crear los slots de despliegue necesarios, sin necesidad de pasar por el Portal de Azure, yendo unos pasos mas allá de lo que vimos anteriormente.

Espero que esta serie les sea útil para mejorar sus despliegues, quedo a la espera de sus comentarios.