Dynamics 365 for Finance & Operations y Azure DevOps (parte I)

Con la llegada de Dynamics 365 el uso de un sistema de control de versiones se ha convertido en obligatorio. En anteriores versiones disponíamos de Morph VCS en AX 2009 y la posibilidad de integrar TFS en AX 2009 y AX 2012 (del que hay un completo curso en El rincón Dynamics), pero no existía ninguna obligación de usar ninguno de los dos. En realidad, siempre según mi experiencia, creo que la mayoría de proyectos se llevaban a cabo sin ningún tipo de control de versiones aparte de, con suerte, comentarios en el código.

El AOT antes de la llegada del control de versiones
El AOT antes de la llegada del control de versiones, de cazapelusas.com

Azure DevOps en MsDyn365FO

En Microsoft Dynamics 365 for Finance and Operations el control de versiones que nos ofrece Azure DevOps no es un simple control de versiones, sino una LA herramienta que hará un poco de Anillo Único en nuestros proyectos (solo que, espero, no para atarnos en las tinieblas). Y es que el cambio no solo afecta al equipo técnico. Desde dirección de proyecto a funcionales pueden implicarse en el uso de Azure DevOps para la gestión del proyecto.

La sincronización del BPM y creación de todas las tareas, planificación del equipo, gestión del código, builds automatizadas y releases que veíamos en un post anterior, son algunas de las herramientas que nos ofrece. Todos estos cambios requieren de un aprendizaje y adaptación por parte del equipo al completo, pero van a ayudarnos mucho en el control del proyecto.

Como decía, puede parecer que el equipo técnico sea el más afectado por la introducción de Azure DevOps por la «obligatoriedad» de usarlo en Visual Studio (bendita obligación), pero también es el que más provecho le va a sacar… 😉

Primeros pasos

Lo primero que tenemos que hacer cuando empezamos un nuevo proyecto de implantación es conectar LCS y el proyecto de Azure DevOps que vayamos a usar. Está todo muy bien explicado en la documentación.

Una vez configurada la conexión tenemos que desplegar el entorno de Build que vimos en el anterior post. Esto se hace habitualmente en la máquina de desarrollo disponible en la suscripción de Microsoft en el proyecto de LCS. Cuando se despliega esta máquina se va a crear la estructura básica de carpetas en el proyecto de DevOps:

Carpetas en proyecto de Azure DevOps

(Ignorad la carpeta CSProjects que es de la actuación cómica del pasado 365 Saturday con mi compañero Juanan)

Con esto ya podemos mapear las máquinas de desarrollo y empezar a trabajar. La carpeta Main que veis en la imagen es una carpeta normal, pero la podremos convertir en una rama en caso de que lo necesitemos.

Carpeta convertida en rama

En la imagen de arriba podemos ver que el icono de Main cambia cuando se convierte en una rama. Las ramas (branches en inglés) nos ofrecen funcionalidades que no están disponibles en las carpetas. Lo podemos ver en el menú contextual:

Menú contextual carpeta
Menú contextual carpeta
Menú contextual rama
Menú contextual rama

Por ejemplo en las ramas podemos ver la jerarquía de las distintas ramas del proyecto (En este caso que sólo trabajamos con dos ramas no parece muy útil :P).

Jerarquía de las ramas

También son distintas las ventanas de propiedades de ambas. Las de una carpeta:

Y las propiedades de una rama, donde podemos ver las relaciones y las ramas que se han creado a partir de ella:

Propiedades de la rama

Todo esto son detallitos, pero quizás lo que mas nos interese de convertir Main en una rama es que nos permitirá ver dónde se ha mergeado qué, como veremos en un próximo post 😛

Un consejo

La carpeta de Projects es buena idea ponerla en la raíz del proyecto de DevOps (al mismo nivel que BuildProcessTemplates y Trunk). Si no se cambia y acabáis trabajando con una rama de dev y la de Main, los check-in de las soluciones y proyectos de Visual Studio se seguirán haciendo en Main (porque la carpeta de proyectos estará ahí). Os ahorrará microinfartos cuando veáis la lista de changesets en el correo de la build de Main 🙂


Y hasta aquí la primera parte del tema. En el próximo post voy a intentar explicar la estrategia de branching que podemos usar en los proyectos y definiciones de build que nos pueden ser útiles.

Builds que no responden en Azure DevOps

Se puede dar el caso de que al lanzar una build no empiecen a procesarse las tareas. Intentas cancelar esa build y… tampoco se cancela. El servidor de build no responde. Pruebas a reiniciar la VM de build y nada. Este caso puede ser un poco raro pero puede pasar.

El servidor de build

El servidor de build es una máquina un poco distinta a las demás de Microsoft Dynamics 365 for Finance and Operations. Aparentemente es exactamente igual que una VM de desarrollo, tiene Visual Studio, tiene un AosService/PackagesLocalDirectory con los modelos y XML de los objetos del AOT, un servidor de SQL y una AxDB y todos los servicios que usa MSDyn365FO (MR, Batch y IIS/IIS Express).

Pero no usamos nada de eso. El «corazón» del servidor de build en realidad es el build agent, una aplicación a la que accede Azure DevOps para realizar algunas de las tareas de cada build. Esto se enlaza al configurar el proyecto de DevOps en LCS como veremos en otro post 😉

Como curiosidad decir que en el futuro no tendremos este servidor sinó bastará con Azure DevOps. He estado buscando la fuente de esto pero no la encuentro, pero creo recordar que Joris de Gruyter lo comentó en Twitter. Si lo encuentro lo voy a linkear.

Edit: sigo sin encontrarlo, pero en este tuit lo deja caer.

El problema

Al final hay poco misterio y todo se ha ocasionado por tener 2 agentes de build configurados en nuestro pool. ¿Cómo ha pasado? Bueno, en nuestro caso, ha sido porque durante un espacio de tiempo muy corto han convivido 2 proyectos de LCS configurados contra el mismo proyecto de Azure DevOps. Es raro sí, tiene una explicación y no ha sido por ningún tipo de chapuza 😉

Esto ha hecho que pasara lo que podéis ver en la imagen:

Dos agentes de build para el mismo proyecto y pool!

Hay dos agentes a la vez y, encima, el que está marcado como activo está offline! Este agente es el del primer proyecto de LCS que se usó, y a pesar de que ya habíamos marcado el correcto como activo se volvió a cambiar solo.

La solución es tan sencilla como conectarse con un administrador de la cuenta de DevOps (no del proyecto en el que estemos), expandir la sección de agentes y borrar el agente offline con la X. Marcar el correcto como activo y ya se retomarán las builds con toda normalidad.

Borrando el agente offline de Azure DevOps

Y nada más, un problema menos.

Configurar Release en Azure DevOps para Dynamics 365 for Finance and Operations

Vamos allá…

Hace unas semanas se publicó en el Marketplace de Azure DevOps la extensión para releases de #MSDyn365FO, con lo que nos acercamos un poco más al escenario de la integración continua. A falta de la documentación oficial tenemos las notas en el anuncio que se hizo, pero vamos a ver paso a paso como configurar todo lo que hace falta para que funcione en nuestro proyecto.

Para configurar el release necesitaremos lo siguiente:

  • Aplicación de AAD
  • Datos del proyecto de LCS
  • Un proyecto de Azure DevOps que esté vinculado al anterior de LCS
  • Usuario tipo cuenta de servicio

Al usuario es recomendable que no le caduque la contraseña (de ahí la cuenta de servicio) y que tenga permisos suficientes tanto en LCS, Azure y Azure DevOps. Esto no es obligatorio, se puede configurar con un usuario normal para hacer pruebas sin ningún problema.

Crear la app de AAD

El primer paso es crear una aplicación de Azure Active Directory para poder subir el paquete generado por la build a LCS, así que nos dirigiremos al portal de Azure y una vez nos hayamos logueado iremos a Azure ActiveDirectory, luego a App Registrations y crearemos una nueva de tipo Native:

Nueva app azure AD

A continuación vamos a «Settings» y «Required permissions» y añadimos la API de Dynamics Lifecycle Services:

Permiso de LCS

Seleccionamos el único permiso disponible en el paso 2 y aceptamos hasta que aparezca el nuevo permiso en la sección «Required permissions». En este paso nos falta únicamente pulsar en «Grant permissions» para que se apliquen los cambios:

Grant permission

Sin este último paso la subida a LCS no se podrá realizar. Una vez hemos hecho esto guardamos el Application ID para usarlo más adelante.

Crear release en Azure DevOps

Antes de configurar nada en Azure DevOps tenemos que asegurarnos que el proyecto que vamos a usar esté vinculado en LCS. Esto lo podemos comprobar en el apartado de «Visual Studio Team Services» en la configuración del proyecto de LCS.

Una vez comprobado esto crearemos la definición de release en DevOps desde Pipelines -> Releases. Seleccionamos «New release pipeline» y del listado que aparece elegimos el «Empty job».

Primero de todo asignaremos a qué build irá vinculada esa definición de release desde «Add an artifact»:

New release

En «Source» seleccionamos la definición de build que queremos usar, en «Default version» usaremos «Latest» y pulsamos «Add».

El siguiente paso es definir la Task con la extensión de release para Dynamics. Pulsamos en la pestaña Tasks y en el botón «+». Nos aparecerá una lista y buscaremos «Dynamics 365 Unified Operations Tools»:

Dynamics 365 Unified Operations Tools

Si no hemos añadido la extensión previamente lo podemos hacer desde esta misma pantalla. Para poderla añadir el usuario con el que estemos creando la release tiene que ser administrador de la cuenta de Azure DevOps en la que esté el proyecto, no es suficiente con que lo sea del proyecto.

Una vez añadida la tarea tenemos que rellenar una serie de parámetros:Release Dynamics Operations

Crear la conexión a LCS

El primer paso es crear la conexión a LCS con la aplicación de AAD que hemos creado antes. Pulsamos New y se abrirá la siguiente ventana:

Coenxión LCS Azure DevOps

Sólo es necesario rellenar el nombre, usuario, contraseña y el Application (Client) ID con el App ID que tenemos del paso inicial en Azure, los campos de «Endpoint» deberían completarse solos. Pulsamos OK y ya tenemos la conexión lista.

En el campo LCS Project Id ponemos el ID que aparece en la URL del proyecto de LCS, por ej. en https://lcs.dynamics.com/V2/ProjectOverview/1234567 el Id es 1234567.

Pulsamos el botón al lado del campo de «File to upload» y seleccionaremos el archivo del deployable package que genera la build:

DP Generado

Dependiendo de si habéis modificado la definición de build o no, el archivo tendrá un nombre u otro, pero normalmente es del tipo AXDeployableRuntime_VERSION_NUMEROBUILD.zip. Cambiad el número fijo de build por la variable de la siguiente manera:

BUildNumber

En «LCS Asset Name» y «LCS Asset Description» se define el nombre y descripción que tendrá el paquete en LCS. Para estos campos podéis usar todas las variables predefinidas de build y de release que ofrece Azure DevOps. Siguiendo con el caso anterior del nombre del archivo, usaremos un prefijo que describa qué tipo de paquete es (para producción o pre-producción) seguido de $(Build.BuildNumber), generando por ejemplo un DP llamado Prod 2019.1.29.1 con la fecha de build.

Ahora ya sólo nos queda guardar y probar. En la pantalla de Releases seleccionamos la que acabamos de crear, le damos al botón «Create a release» y sin cambiar ninguna opción seleccionamos OK en la pantalla que se ha abierto. Se lanzará la release y si todo va bien podremos ver el paquete en LCS:

LCS Asset Library

Si queremos automatizar la parte de release y que se ejecute cada vez que termine una build sólo tenemos que activar el trigger en el artefacto:

Release trigger

Desde el botón del rayo se nos abre un diálogo y simplemente hay que marcar la opción que aparece.

Nada más, con estos pasos ya tendremos configuradas las builds (que pueden estar automatizadas también) y los releases. Sólo falta que los despliegues también se puedan automatizar y ya estaremos en la integración continua que comentaba al principio.