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
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.Clipboard30
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.Clipboard31
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.Clipboard32
Aquí se nos ofrecerá la opción para ubicar la solución respectiva que ya ha sido subido al repositorio Git.Clipboard33
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.
Clipboard35

Le damos a grabar y de paso le asignamos un nombre, en este caso ConsultorInternetPUBuild1:Clipboard36
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.Clipboard37
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.Clipboard38
Luego de la modificación subimos los cambios (Commit) y veremos que tenemos una nueva Build encolada, esperando iniciar su ejecución.Clipboard39
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.Clipboard40

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.Clipboard41
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.Clipboard42
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.Clipboard43
Aquí nos corresponder agregar los detalles de nuestra subscripción a fin de establecer el enlace.Clipboard44
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.Clipboard45
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…”Clipboard46
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.Clipboard47
Vamos a la web y vemos que figura el texto en cuestión.Clipboard48

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.

Clipboardqa13

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.

Clipboardqa14

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.

Agregue un comentario

Su dirección de correo no se hará público.

Time limit is exhausted. Please reload the CAPTCHA.