Procesos BUILD Automáticos Con TFS Y AX 2012 (2/2) (ALM-X)

Tue, Jan 12, 2016
6-minute read

Warning: This post is over 365 days old. The information may be out of date.

En el artículo anterior de esta serie definimos el proceso principal para configurar una Build de Microsoft Dynamics AX 2012 en TFS, en resumen:

Instalar y configurar los componentes de TFS necesarios en el servidor de build (Agente, Controlador, etc.).
Crear un nuevo proyecto con las actividades personalizadas y la plantilla por defecto.
Subir todo esto al repositorio de código fuente en TFS o Team Services para que el Controlador pueda acceder a ellos.
Añadir estas referencias a Visual Studio para que éste reconozca las actividades nuevas.
Crear una nueva definición de Build utilizando la plantilla descargada.

Nos quedábamos ejecutando esta definición de Build recién creada con todas las opciones, actividades y plantilla por defecto, y tras todo lo cual recibíamos un error. Frustrante, ¿No? Puede que si, pero si lo pensamos es bastante lógico, veamos:

Una Build no es más que un workflow que ejecuta una serie de pasos en un determinado orden. Este workflow es la Plantilla (template) que nos hemos descargado, un fichero con extensión XAML que, si hemos seguido todos los pasos hasta aquí, podremos incluir en un proyecto o solución de Visual Studio y editarlo desde ahí, y que tiene este aspecto:

Esta plantilla está compuesta por nodos que representan las acciones que se van a ir ejecutando, incluyendo tanto acciones por defecto del sistema (básicamente las que controlan el flujo de ejecución), como acciones nuevas que hemos añadido a través de los ensamblados que hemos descargado de codeplex, a estos nodos o acciones las llamamos Actividades (activities).

Estas actividades realizan tareas específicas y concretas como ejecutar un script de PowerShell, controlar el flujo permitiendo condiciones (if) o bucles, o en nuestro caso cosas como compilar el código X++, compilar CIL, sincronizar la base de datos de AX, manejar modelos, etc., tienen este aspecto en el toolbox de Visual Studio:

Es por esto que una plantilla genérica descargada de internet no es probable que funcione al primer intento, tal como nos ocurrió en el capítulo anterior. Este workflow debe ser adaptado a nuestros entornos, a nuestros servidores, debemos especificar si los pasos son los correctos y, aunque lo fueran, configurar determinados aspectos específicos en cada caso como el nombre de los servidores, las rutas del disco donde almacenar los objetos que maneja la build (ficheros XPO por ejemplo), etc.

En la anterior imagen mostraba el workflow por defecto que Joris comparte en su web, que es un muy bueno como punto de partida para empezar, a continuación os muestro un workflow utilizado en un entorno real para que se pueda apreciar la diferencia, y la potencia que nos ofrece poder modificar exactamente cómo queremos construir nuestra aplicación:

Como decía, si hemos seguido los pasos de los artículos anteriores de esta serie, podremos incluir la plantilla descargada en un proyecto de Visual Studio con las referencias correctas para poder editarla. Veremos el workflow en la ventana principal de Visual Studio, las actividades que podemos arrastrar y soltar al workflow en la ventana Toolbox (mostrarla desde el menú View si no está visible) y cada uno de las actividades nos mostrará sus propiedades, que serán lógicamente diferentes dependiendo del tipo de actividad:

Joris hizo un buen trabajo diseñando las actividades, de manera que todas las que tienen que ver con AX utilizan unos parámetros coherentes con el resto, recibiéndo parámetros comunes que podemos almacenar en variables del proceso para facilitar el mantenimiento, ya sea variables internas que el proceso puede utilizar, o parámetros de entrada que recibe de forma externa, para así poder cambiar el comportamiento de la Build sin tener que modificar la plantilla cada vez:

Los Argumentos del proceso nos permiten definir parámetros de entrada, que podremos pasar al proceso cuando elijamos esta plantilla en la Definición de Build, al crearla. Muy útil para tener diferentes Builds (diferentes definiciones) que, utilizando la misma plantilla, realizan diferentes acciones dependiendo de los parámetros de entrada de cada definición. Por ejemplo, compilar una Rama u otra, o utilizar diferentes entornos para compilar dependiendo de un fichero de configuración:

Esto no se incluye en la plantilla por defecto, así que será tarea nuestra modificarla, bien simplemente para cambiar las rutas y valores apropiados a nuestros entornos, bien para sustituir estos valores por variables tal como he hecho yo, y a partir de aquí no hay una norma ni balas de plata, todo depende del esfuerzo que queramos dedicar al proceso y a lo que queramos conseguir con nuestros procesos.

Una vez terminada nuestra plantilla, e incluso mientras la estamos desarrollando, el proceso muestra cada una de las actividades que va ejecutando y el tiempo que tarda en cada una de ellas. Ésto nos va a permitir comprobar qué va haciendo y en caso de problemas, saber cuál de las actividades ha fallado. Se almacena un log de todas las Builds ejecutadas, aunque podemos cambiar la política de retención en la definición ya que probablemente no queramos guardar el resultado de todas las builds ejecutadas desde siempre, sino sólo las que nos sean útiles.

Tanto si la build termina correctamente como si da algún error, se nos muestra un informe detallado al finalizar que puede verse tanto en Visual Studio como en la web de TFS, ya usemos TFS on premise o Visual Studio Team Services.

La Build también guarda información muy útil en el disco duro del servidor (por defecto), o donde le indiquemos que lo haga. Es nuestra responsabilidad definir cuál es el resultado que queremos obtener del proceso, que puede ser desde símplemente compilar el código, un XPO con los objetos, un modelo, una model store, etc… podemos combinar las actividades para obtener lo que queramos. En cualquier caso, probablemente guardemos este resultado en el disco, donde el propio proceso almacena todo el código descargado de TFS, y las actividades de AX almacenan ficheros temporales utilizados durante el proceso.

Además, TFS almacena un log muy completo que incluye información detallada para cada actividad, incluyendo los parámetros de entrada y cualquier información de salida, dependiendo de la actividad. Estos logs son muy útiles para depurar nuevas plantillas al crearlas, y también para diagnosticar problemas en Builds reales que puedan fallar.

Si una build falla, siempre podemos re-lanzarla utilizando la opción Retry Build en Visual Studio.

O bien podemos ejecutarla directamente desde el portal web, muy útil ya que podemos ejecutar una nueva Build sin necesidad de tener acceso al servidor donde se ejecuta. Normalmente la web de TFS será más accesible que los propios servidores donde se ejecuta el proceso.

Call to action!

Hace mucho que empecé a escribir esta serie y espero que haya sido útil a alguien, que algún equipo trabaje ahora más tranquilo gracias a las técnicas aprendidas aquí, entonces todo este trabajo habrá valido la pena. ¿Es tu caso? ¿Esta serie de artículos te han ayudado? Si es así por favor cuéntamelo por mail, twitter, en el formulario de contacto,… en fin, como quieras. Estoy preparando otro proyecto relacionado con este tema y me ayudaria conocer tus impresiones. Al fin y al cabo esto no sirve de nada si no resulta interesante para la comunidad.

¡Gracias! :D

Posts in this series

Spanish ALM DevOps Dynamics AX PowerShell