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:
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.
Si usas una instancia regional de LCS para tu proyecto, necesitas tener en cuenta que el endpoint del campo «Lifecycle Service API Endpoint» tiene que actualizarse con el valor correspondiente:
¡Gracias a Søren Printz Christensen por este dato!
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:
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:
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:
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:
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.
¡Y ya esta todo listo! Un pasito más cerca de deshacernos de las VM de build.
Autenticación MSAL, nuevas tareas de Azure DevOps y fin de soporte a ADAL #
Se ha publicado una nueva versión de las tareas para nuestros pipelines que usan los agentes de Azure. Estos cambios se han introducido recientemente para dar soporte a las librerías de autenticación MSAL para la conexión de LCS que utilizamos para subir y desplegar los deployable packages.
Las conexiones que tenemos ahora usan la Azure Active Directory (Azure AD) Authentication Library (ADAL), y el soporte para ADAL va a terminar en junio de 2022.
Esto quiere decir que si no actualizamos las tareas de Asset Upload y Asset Deployment a las nuevas versiones (1.* y 2.* respectivamente) los pipelines de release podrían dejar de funcionar después del 30 de junio de 2022.
Agradecer a Joris de Gruyter el chivatazo que ha permitido escribir este post 😛
También tenemos una tarea nueva que añade el soporte para la autenticación MSAL. Esta tarea instalará las librerías de PowerShell de MSAL en nuestro agente de Azure y tenemos que añadirlo antes de que se autentique cualquier task. Debería quedar así:
Tarea instalar MSAL
Esta nueva tarea no tiene parámetros u opciones que tengan que completarse, solo tenemos que añadirla a nuestro pipeline y ya está.
Si tenéis un pipeline de release con varios stages, habrá que añadir esta nueva tarea en cada stage en los que vaya a haber autenticación. Si por ejemplo lo ponéis en el primero, donde se hace la subida a LCS, y en otro se hace el despliegue y no tiene esta task, va a fallar. Esto por lo menos es cierto si el proyecto tiene agentes adicionales, tengo que probarlo con un proyecto con un único agente.
Si cambias la versión de la tarea Asset Upload de 0.* a 1.* no verás cambios. Los campos de la task son los mismos, pero va a usar la autenticación MSAL como nueva forma de autenticación.
Pero cuidado, solo con cambiar la versión no es suficiente. También tenemos que crear una conexión de servicio nueva porque el endpoint ha cambiado a https://login.microsoftonline.com/organizations. Este endpoint será el que, a partir de ahora, se use en todas las versiones cuando se genere una nueva conexión, sea en la versión de la tarea que sea.
Aquí podéis ver el antiguo endpoint:
En la tarea Asset Deployment ahora veremos tres versiones: 0.* que es la original, 1.* que es la que dio soporte a los entornos self-service, y la 2.* que es la nueva que soporta la autenticación MSAL.
Si ya has creado la conexión en el paso anterior con cambiarla a la nueva ya lo tienes listo.
No lo sé seguro. Pero seguramente con instalar la librería de PowerShell MSAL.PS en vuestra máquina de build debería bastar, si es que no está ya instalado.
