Configurar las nuevas tareas de Azure DevOps para generar el paquete y versiones de modelos

Durante la pasada noche (que por lo menos era noche para mí :P) se han publicado las nuevas tareas de Azure DevOps para desplegar los paquetes, actualizar versiones de modelos y añadir licencias a los DPs:

Se ha publicado tambien un anuncio en los blogs de Community con más detalles acerca de la configuración. Vamos a ver las nuevas tareas y cómo configurarlas.

Tarea Update Model Version

Esta es sencillita, simplemente hay que añadirla a tu definición de build debajo de la tarea actual, deshabilitas la original y listo. Si tienes algún filtro, excluyendo modelos por ej., necesitaras crear el filtro en el campo Descriptor Search Pattern usando la sintaxis de patrones de Azure DevOps.

Tarea Create Deployable Package

Esta tarea va a sustituir la Generate packages actual. Para configurarla correctamente necesitamos hacer un par de cambios a los valores que trae por defecto:

X++ Tools Path

Esto es el directorio físico de tu VM de build donde está la carpeta bin. La carpeta AosService normalmente está en la unidad K en las VMs desplegadas en la suscripción del cliente. Probablemente esto cambie cuando pasemos a un modelo sin VMs para hacer las builds.

Edito!: la ruta a la unidad se puede cambiar por $(ServiceDrive), quedando una ruta como $(ServiceDrive)\AOSService\PackagesLocalDirectory\bin.

Location of the X++ binaries to package

La tarea viene con este campo rellenado con $(Build.BinariesDirectory) por defecto, pero esto no nos ha funcionado para nuestras builds, quizás esa variable no esta en el archivo proj. Sólo hay que cambiarlo por $(Agent.BuildDirectory)\Bin y el DP se generará sin problemas.

Filename and path for the deployable package

La ruta en la imagen debería cambiarse por $(Build.ArtifactStagingDirectory)\Packages\AXDeployableRuntime_$(Build.BuildNumber).zip. Se puede dejar sin la parte de Packages pero entonces habra que cambiar el campo Path to Publish de la tarea Publish Artifact: Package de la definición.

Tarea Add Licenses to Deployable Package

Esta tarea añade las licencias a un Deployable Package que ya existe. Recuerda que la ruta del DP tiene que ser la misma que hayas configurado en la tarea Create Deployable Package.

¡Y ya esta todo listo! Un pasito más cerca de deshacernos de las VM de build.

Si necesitas ayuda para configurar Configurar Release en Azure DevOps puedes leer este post que escribí.

 

Entornos self-service: el futuro que ya está aquí

Ahora mismo Microsoft Dynamics 365 for Finance and Operations tiene una arquitectura de tipo monolítico, aunque está en la nube de Azure lo que tenemos en realidad es una (o varias en el caso de los entornos Tier 2+) máquina virtual que ejecuta todo: el AOS/IIS, Azure SQL Server, el servicio de lotes, MR, etc. Igual que teníamos en AX 2009/2012.

Esto va a cambiar en los próximos meses con los entornos self-service (o autogestionados). Vamos a pasar de una arquitectura monolítica a una de microservicios que ejecutarán todos los componentes con la ayuda de Azure Service Fabric. MSDyn365FO estará finalmente en un modelo SAAS real.

Antes de empezar quiero dejar claro que todos estos cambios solo afectan a los entornos Tier 2+ gestionados por Microsoft: entornos de tipo sandbox y producción. El entorno de build (hasta que desaparezca) y los entornos hospedados en la nube de la suscripción del partner o cliente seguirán siendo máquinas virtuales.

¿Qué cambia?

Despliegues más rápidos

Cuando despliegues un nuevo entorno se va a iniciar el despliegue en el momento, sin esperar a que lo haga Microsoft (es self-service). Además, gracias a la nueva arquitectura de microservicios, estará disponible en unos 30 minutos en comparación con las 6-8 horas que hay que esperar ahora. La primera vez parece…

Estimación de suscripción

Seguimos necesitando rellenar la estimación de la suscripción por un tema de licencias y para que MS estime la capacidad que debe asignar al entorno de producción. Los entornos self-service se pueden escalar más rápido (poner o quitar un AOS por ej.).

No hay acceso por RDP

El acceso al escritorio de la VM se ha quitado porque… bueno, supongo que es porque no hay una VM ya. Todas las operaciones que necesitaran que accedieramos al RDP se podrán hacer desde LCS.

No hay acceso a SQL Server

Exacto, que no haya acceso por RDP quiere decir que tampoco podemos acceder por RDP a la máquina de SQL. Seguimos teniendo acceso a la DB en Azure SQL, sólo tenemos que solicitarlo desde LCS y se activa en unos segundos:

Además hay que poner la IP desde la que se vaya a conectar a SQL en la withelist desde el botón Maintain – Enable access de LCS para poder conectar al Azure SQL Server. El acceso a la DB y la regla en el firewall estarán activos durante 8 horas.

Como siempre, no tenemos acceso a la DB de producción.

Un deployable package para gobernarlos a todos

Si has intentado desplegar un deployable package (DP) que no tenga todos los paquetes o modelos que tiene el entorno (básicamente creando el DP desde Visual Studio) habrás visto que aparece un aviso sobre la diferencia entre entorno y DP.

Con los entornos self-service tienes que incluir todos los modelos/paquetes Y!!! ISVs en un único DP.

Actualizar producción

Primero de todo, podemos lanzar la actualización de producción sin las 5 horas de preaviso que necesitamos ahora. Seguimos pudiendo programar el despliegue pero también lo podemos iniciar en el momento.

Después, la forma en la que se actualiza el entorno de producción ha cambiado un poco de lo que hacemos ahora. Con los nuevos entornos lo que haremos será actualizar un entorno de sandbox como hacemos ahora, y una vez esté hecho, seleccionaremos el entorno de sandbox para promocionarlo a producción. Esto supongo que es otro beneficio de los cambios de arquitectura.

En el futuro el tiempo de mantenimiento también se reducirá a cero para las actualizaciones de servicio siempre que estemos en la última actualización. Esto no será posible para DPs con código nuestro.

¿Cómo consigo estos entornos?

Por el momento esto sólo está disponible para algunos nuevos clientes. Los clientes actuales serán migrados en los próximos meses, Microsoft los contactará para programar una ventana de mantenimiento para aplicar los cambios.

Para más información podéis ver la sesión Microsoft Dynamics 365 for Finance and Operations: Strategic Lifecycle Services Investments del MBAS del pasado junio.

Nuestra experiencia

Llevamos en la preview privada desde hace casi un año con uno de los clientes de Axazure. El cliente ya está con producción en live con un entorno self-service y ha ido todo bien.

Pero los inicios fueron un poco duros. Muchas de las funcionalidades aun no estbaan disponibles en ese momento, como el refresco de DB o… el despliegue de DPs. Sí, teníamos que solicitar a MS cada vez que queríamos subir cambios a un entorno. ¡No podíamos ni poner los entornos en mantenimiento! En los primeros meses de 2019 se añadió un montón de funcionalidad a LCS, y en junio finalmente pudimos hacer los despliegues en producción nosotros mismos. La ayuda que hemos tendido por parte del equipo de producto de Microsoft ha sido clave y nos han desbloqueado algunos problemas que estaban deteniendo el progreso del proyecto.