Thumbnail image

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

  • Thu, Dec 3, 2015
  • 8-minute read
!
Warning: This post is over 365 days old. The information may be out of date.

Table of Contents

En los post anteriores de esta serie hemos visto cómo configurar un servidor TFS (local o en la nube) y cómo utilizarlo para gestionar nuestras tareas, controlar el código fuente y gestionar versiones mediante ramas, entre otras cosas. Para cerrar el círculo debemos procesar toda esa información, código y versiones en algo que podamos entregar a nuestros clientes/usuarios.

Aquí es donde entran en juego los procesos automáticos de construcción y compilado, llamados procesos Build. Ejecutar una Build en TFS es relativamente sencillo si trabajamos con lenguajes .NET, pero para hacerlo con AX tendremos que trabajar un poco antes para preparar el entorno e instalar los componentes necesarios en los servidores.

Tenemos un resumen bastante bueno de los componentes necesarios a nivel general en el siguiente enlace. Los componentes a instalar dependerá de si utilizamos un TFS local o en la nube.

Primero debemos familiarizarnos con algunos conceptos clave:

  • Build Service: Servicio que acepta peticiones de ejecución de Build.
    • Un servicio está asociado a una colección de proyectos en TFS.
    • Habitualmente sólo necesitamos un servicio por colección de proyectos.
  • Build Controller: Orquesta la Build y delega el trabajo en los Build Agents.
    • Un controlador está asociado a un Build service.
    • Puede que necesitemos varios controladores si tenemos varios entornos preparados para ejecutar Build. En ese caso asignaremos lo agentes a cada controlador para crear diferentes colas de proceso.
  • Build Agent: Servicio que realiza la Build.
    • Un agente se registra en un controlador
    • Debe instalarse en la misma máquina que el AOS que va a ejecutar el proceso
    • Se debe instalar un agente por cada AOS que tengamos procesando Build.

Es posible instalar y ejecutar varios servicios, controladores y agentes, pero para empezar es suficiente con instalar uno de cada. En nuestro caso es necesario que todos estos componentes estén instalados en nuestros servidores, ya que van a requerir utilizar instancias de AX. Pero el código fuente puede estar en una instancia de TFS en la nube sin ningún problema, cada componente puede estar en servidores diferentes, como se muestra en el siguiente esquema:

VSO Build Overview

Preparación de los componentes necesarios para AX 2012

El proceso de Build es básicamente un proceso workflow en el que se van ejecutando acciones paso a paso. En TFS, estas acciones se llaman Actividades (Activities) y al fichero que almacena el workflow se le llama Plantilla (Template). La instalación por defecto de TFS trae plantillas y actividades preparadas para compilar proyectos .NET sin ningún esfuerzo. Pero como sabemos, compilar aplicaciones AX no es tan sencillo así que debemos crear nuestra propia plantilla que realice un proceso personalizado, utilizando actividades también personalizadas para realizar acciones propias de AX como sincronizar la base de datos, compilar CIL, etc.

Microsoft no dispone de estas plantillas oficialmente, aunque de facto todo el mundo utiliza las publicadas en el proyecto Dynamics AX Admin Utilities originalmente creado por Joris de Gruyter (junto a una serie de artículos que empiezan aquí) y al que contribuyen otros miembros de la comunidad. Lo primero que haremos será descargar las actividades y la plantilla de ejemplo desde la propia web de CodePlex.

La versión a descargar va a depender de tu versión de TFS y AX (también existen para 2009, aunque quedan fuera de este artículo):

Para facilitarnos el trabajo, vamos a preparar un proyecto donde trabajar y subir los ensamblados al control de codigo fuente de TFS. Para ello hacemos lo siguiente:

  • Crear un nuevo proyecto o solución en Visual Studio
  • Añadir al proyecto todas las librerías que hemos descargado. En el proyecto de VS se pueden crear carpetas para mantener los ficheros ordenados. Yo las voy a poner en una carpeta llamada CodeCrib.
  • Como consejo personal, yo añado a esta carpeta también los ensamblados AXUtilLib.dll y AXUtilLib.PowerShell.dll, que podemos encontrar en algún servidor de AX que tengamos disponible, por defecto en la carpeta C:\Program Files\Microsoft Dynamics AX\60\ManagementUtilities\
  • Añadir todos estos ensamblados como Referencias del nuevo proyecto. En la carpeta References > Add references > Browse y elegir la carpeta donde las hayamos puesto, dentro del proyecto. Seleccionarlas todas y OK.
  • Incluimos también la plantilla de ejemplo descargada anteriormente, es un fichero XAML (no subir el ZIP!).
  • Subimos todo el proyecto a una carpeta en nuestro código fuente. Por defecto los proyectos de TFS incluyen una carpeta BuildProcessTemplates, este es un buen lugar para poner nuestras librerías.
  • Una vez ordenado todo y subido al código fuente, el proyecto queda más o menos así:
  • Un último paso es indicarle a Visual Studio dónde están las actividades personalizadas. Para ello hacemos botón derecho en algún nodo del Toolbox de actividades, elegimos Choose Items y en System.Activities utilizamos el botón Browse para buscar el fichero CodeCrib.AX.TFS. Esto añade todas las actividades para AX a la lista, seleccionamos todas ellas y pulsamos OK.
  • Más adelante vamos a necesitar todo esto, pero de momento guardar todo, check-in al source control y seguimos instalando componentes.

Instalar servicios Build de TFS en nuestros servidores

A continuación vamos a instalar los componentes necesarios para ejecutar Builds TFS en nuestros servidores. Si ya has instalado algún servicio de Build puedes pasar al siguiente paso.

Como comentamos anteriormente, ya usemos un TFS en la nube o en nuestros servidores, los componentes necesarios para ejecutar AX durante las Builds hay que instalarlos obligatoriamente en las máquinas locales. Tener en cuenta que para ejecutar estos componentes hacen falta permisos muy elevados en la colección de proyectos de TFS y en el servidor donde se instalan.

Si todavía no tenemos instalado ningún componente, utilizamos el instalador de TFS para iniciar el asistente de configuración de un nuevo servicio Build.

  • Empezamos conectando a nuestra instancia de TFS (ya sea local o en la nube) para indicar la URL de nuestra colección de proyectos.
  • En el siguiente paso elegimos instalar un solo servicio de Build con las opciones por defecto.
  • Especificamos un usuario del dominio encargado de ejecutar el servicio. Es recomendable utilizar un usuario dedicado para esta tarea, pero de momento utilizo el Administrador para esta demo.
  • Cuando el asistente termine la instalación, pulsamos el botón Configure y si todo va bien, la instalación ha terminado.

Configurar servicios Build de TFS para trabajar con AX 2012

Si en este punto vamos a Visual Studio e intentamos ejecutar una nueva Build, podemos seleccionar el controlador/servicio recién instalado. Pero sólo podremos elegir las plantillas por defecto de Visual Studio dedicadas al compilado de soluciones .NET. Para decirle a TFS que debemos ejecutar nuestro propio workflow todavía necesitamos un poco de configuración extra.

Utilizamos la Team Foundation Server Administration Console para configurar las propiedades, primero, del controlador recién instalado. Aquí podemos cambiar el nombre del controlador y el máximo número de Builds concurrentes (debe ser 1 como máximo). Pero lo más importante es que podemos decirle al controlador dónde están nuestros ensamblados personalizados. Utilizaremos la propiedad Version control path to custom assemblies para indicar la carpeta del código fuente donde subimos nuestros ensamblados personalizados con las actividades que vamos a utilizar en las Build de AX 2012.

Ejecutar nuestra primera Build de AX 2012 en TFS

Ya hemos instalado y configurado lo necesario para ejecutar una primera Build de nuestro código fuente, para ello haremos lo siguiente:

  • En Visual Studio vamos al panel Team Explorer > Builds y elegimos New Build Definition para crear una definición nueva. Esta es la definición que utilizaremos en adelante para ejecutar y revisar nuestro proceso, podemos crear tantas definiciones como queramos, con diferentes parámetros de entrada y asociadas a las mismas o a diferentes plantillas.
  • En la pestaña Build Defaults elegimos nuestro controlador y dónde queremos que la Build ponga los ficheros de salida del proceso. Estos ficheros dependerá de nuestras necesidades y del proceso que se ejecute efectivamente en la plantilla. En caso de AX puede ser un modelo, una Model Store, etc. Podemos almacenar estos ficheros en el propio control de versiones o en una carpeta de un servidor de ficheros por ejemplo. En caso de procesos Build que sólo nos sirvan para comprobar el compilado de los objetos podemos indicar que no se guarden estos ficheros para ahorrar algo de espacio en disco.
  • En la pestaña Process elegimos la plantilla que queremos ejecutar y los parámetros de entrada de esta plantilla. Como es la primera vez que utilizamos nuestra plantilla para AX 2012 no aparece en el desplegable. Pulsamos New y la buscamos en la carpeta donde la guardamos dentro del código fuente.
  • Una vez elegida al plantilla, el formulario se actualiza con los parámetros definidos en ella. La plantilla que nos hemos bajado de la web de Joris sólo nos pide la ruta de un fichero de configuración que utilizará el proceso Build para conectar a una instancia de AOS para ejecutar todo el trabajo. Debe ser un entorno dedicado a esta tarea y estar instalado en el mismo servidor donde instalamos el controlador.

  • Guardamos la definición del proceso y ya podemos ejecutarlo desde Visual Studio o desde la web de TFS (ya sea en la nube o local). Probablemente el proceso fallará, ya que la plantilla de Joris está pensada para su servidor y su entorno, es casi imposible hacer una plantilla universal en el caso de AX.
  • En cualquier caso la Build nos va a mostrar un log con lo que ha ocurrido para permitirnos corregir cualquier incoherencia. Siempre podremos volver a este log desde el historial de Build en Visual Studio o en la web de TFS, y también podemos consultar la carpeta de salida de la Build que hemos configurado antes, donde el proceso guarda un log muy detallado de cada actividad y su resultado.

Esto ha quedado ya demasiado largo, así que veremos cómo arreglarlo y crear nuestras propias plantillas en la segunda y última parte de este artículo :)

Posts in this series

Spanish ALMDevOpsDynamics AXPowerShell