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.
Si habitualmente recibes los correos de notificación de LCS de tus proyectos ya sabrás esto: todas las máquinas Tier 1 gestionadas por Microsoft desaparecerán a partir del 1 de diciembre!
¿Como que desaparecerán?
Esto es lo que dice el correo:
As communicated previously, Microsoft is removing the use of Remote Desktop Protocol (RDP) to access environments managed by Microsoft. As RDP access is required for development, going forward customers will be required to develop using a Cloud Hosted Environment or download a local “Virtual Hard Disk” (VHD) within Lifecycle Services. Cloud Hosted Environments will allow customers to manage the compute, size, and cost of these environments. This infrastructure change will ensure that customers decouple development tools from any running environment.
In addition, effective November 1, Tier 1 environments will not be included in the purchase of Dynamics 365 Finance, Dynamics 365 Supply Chain Management, Dynamics 365 Project Operations, or Dynamics 365 Commerce apps. The ability to purchase additional Add-On tier 1 environments will also be removed at this time. Beginning December 1, Remote Desktop Protocol (RDP) access for the existing Tier 1 Developer environments, managed by Microsoft, will be removed and decommissioned. Customers will need to preserve or move data within these environments by this date. See the FAQ below with links to existing documentation.
Microsoft will continue to invest in development tools and processes to allow customers to extend the rich capabilities available within Dynamics 365. Learn about one of these key investments, which allows for build automation that uses Microsoft-hosted agents and Azure Pipelines. This approach helps customers avoid the setup, maintenance, and cost of deploying build virtual machines (VMs). It also reuses the existing setup of build agents to run other .Net build automation.
Azure credits will be provided for qualifying customers to use for deploying Tier 1’s using Cloud Hosted Environments. Complete this survey to submit your request.
Sinceramente ha sido un poco de sorpresa. Se había informado que los accesos por RDP iban a desaparecer como pone en el correo, y la desaparición de la máquina de build lleva siendo un rumor desde hace 2 años por lo menos. Pero esto es bastante drástico y ¡con muy poco tiempo de aviso! ¡Quedan menos de dos meses para diciembre!
Pero esperad… en vez de especular, Evaldas Landauskas ha preguntado a microsoft y parece que las máquinas no se borrarán de inmediato el día 1 sino progresivamente:
FYI: I have asked MS about this topic and this is the answer I have got.
"The process will start with removal of RDP and eventually we will decommission these environments after no activity."
So it won't be decomissioned immediately if it's in use.
Esta noche hemos recibido otro correo de LCS con más detalles y fechas actualizadas. Así que al final se ha aplazado todo un poco y este es el plan:
1 de noviembre de 2020: no se podrán desplegar ni adquirir más entornos Tier 1. Los que no estén desplegados se borrarán.
1 de diciembre de 2020: se eliminará el acceso por RDP.
30 de enero de 2021: se mandarán notificaciones sobre el parado y borrado de las VM Tier 1.
¿Qué hacer ahora?
Esto depende de qué uso estés haciendo de la máquina y si tienes entornos Tier 1 add-on. Y otra prgunta seguramente sea el coste de reemplazar esa máquina virtual.
Sólo la uso como servidor de build
Si sólo usas la máquina Tier 1 como servidor de build tienes dos opciones:
Necesitarás una máquina virtual de build si ejecutas tests o sincronizas la DB como parte de tu proceso de build. Es la única forma. Sobre los costes: podrías desplegar una VM de tipo B8MS con 2 discos SSD Premium de 128GB por unos 280€ al mes. Incluso se podría probar a usar una B4MS por unos 160€/mes.
Esto es más o menos lo mismo que cuesta una máquina Tier 1 de las gestionadas por Microsoft. Y si sólo ejecutas los tests y la sincronización una vez al día puedes rebajar los costes un poco más si arrancas y paras la VM desde tu pipeline.
Si no lo necesitáis, o queréis una build de CI que sólo compile el código, simplemente configurad las builds hospedadas de Azure.
La uso de máquina de desarrollo
Si usas máquinas gestionadas por microsoft add-on ara desarrollo tendrás que desplegar nuevas máquinas de desarrollo en tu suscripción (o la de tu cliente).
¿Preocupados por el coste extra? No lo estéis. Si desplegáis máquinas DS12 V2, con 3 discos SSD Premium de 128GB, y las usáis durante 8 horas al día, 20 días al més, el coste es de unos 120€ al mes.
En ambos casos, si leéis el correo, veréis que Microsoft dará créditos de Azure en compensación por estas VMs, pero no sabemos cuántos. Espero que esto haga la transición más sencilla pero estoy seguro que habrá bastante gente quejándose 😂
El nuevo endpoint de la LCS DB API para exportar una base de datos ha sido publicado! Con él ya tenemos una forma de automatizar el refresco de datos de tu Dynamics 365 FnO desde producción a un entorno de desarrollo Tier 1.
LCS DB API Automation
Puedes aprender más acerca de la LCS DB API leyendo estos posts que escribí hace un tiempo. Es una buena idea echarles un vistazo porque hay algunos pasos que doy por explicados:
Recordar que esto esta en preview privada. Si queréis uniros a la preview primero necesitáis ser parte del Insider Program donde podéis uniros al «Dynamics 365 for Finance and Operations Insider Community«. Una vez invitados a la organización de Yammer podéis pedir acceso al grupo «Self-Service Database Movement / DataALM» donde recibiréis toda la info necesaria para uniros a la preview y activar la funcionalidad en LCS.
Los dos últimos proyectos que he empezado están en self-service y también hemos tenido la migración de un cliente que estaba en la infraestructura normal. Así que ya es hora de que os avise sobre una cosa terrible…
Hace no mucho hablé en otro post sobre la API de movimiento de base de datos de LCS, y en este quiero mostrar como llamar a la API usando PowerShell desde nuestras pipelines de Azure DevOps.
¿Para qué?
Básicamente por automatización. Ahora mismo la API sólo permite el refresco de un entorno de Microsoft Dynamics 365 for Finance and Operations a otro, así que la idea es tener datos frescos de producción en nuestros entornos de UAT a diario. No sé qué nuevas operaciones soportará la API en el futuro pero otra idea sería añadir al pipeline la exportación de la DB (creando un bacpac) de un entorno de UAT para tener datos listos para restarurar en una máquina de desarrollo.
Desde el pasado octubre hemos podido probar la preview de la Database Movement API que nos permite listar y descargar copias de las DBs que tenemos en LCS y lanzar refrescos de datos usando una API REST.
Si queréis uniros a la preview primero necesitáis ser parte del Insider Program donde podéis uniros al «Dynamics 365 for Finance and Operations Insider Community«. Una vez invitados a la organización de Yammer podéis pedir acceso al grupo «Self-Service Database Movement / DataALM» donde recibiréis toda la info necesaria para uniros a la preview y activar la funcionalidad en LCS.
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.
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.
He estado en la preview privada desde hace casi un año con un cliente. 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.
