Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y 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.

¡Suscríbete!

Recibe un correo cuando se publique un nuevo post
Author

Microsoft Dynamics 365 Finance & Operations technical architect and developer. Business Applications MVP since 2020.

Write A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

ariste.info