Category

Azure DevOps

Category

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!

Tier 1 VMs will be gone
¿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:

¡Actualización!

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:

  • Desplegar una máquina de build en tu suscripción
  • Configurar las builds en Azure

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 😂

Podéis leer sobre algunos usos más de la máquina Tier 1 en el blog de Nathan Clouse.

Estoy seguro de que muchos de nosotros hemos tenido que desarrollar algún tipo de librería en .NET para solucionar algo en Dynamics 365 Finance and Operations. Creas un proyecto de C#, lo compilas y añades la referencia en tu proyecto de FnO. ¡Ya no tienes que hacer eso! Puedes añadir el proyecto a tu repositorio de código, compilarlo en tu pipeline y ¡la DLL se añade al deployable package!

He estado haciendo estas pruebas a raíz de una conversación en Yammer, y a pesar de que he conseguido compilar .NET y X++ en la misma pipeline sin problemas, he encontrado algun problema o limitación.

Si quieres leer más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.

He escrito este post después de que lo sugiriera Mötz Jensen en un largo y muy interesante hilo de Twitter acerca de control de versiones para Dynamics 365 for Finance and Operations. Este es el tweet de Denis Trunin que lo ha iniciado todo:

¡Contemplad #XppGroupies! ¡El día que tanto hemos estado esperando ha llegado! Las Azure hosted builds (me cuesta mucho decir Build hospedada en Azure) ya están en preview pública con el PU35!! Ya podemos dejar de preguntarle a Joris cuando estará disponible, porque ya lo está!! Leed los Docs!!

He podido escribir esto porque, gracias a Antonio Gilabert, hemos podido probarlo durante la preview privada en Axazure durante unos meses. Y por supuesto gracias a Joris por habernos invitado a la preview!

Azure hosted builds
Cabalgando los Azure Pipelines por Caza Pelusas

¿Qué significa esto? No necesitamos ya la VM para ejecutar pipelines! Es broma, sí la necesitamos! Si estámos ejecutando tests o sincronizando la DB como parte de nuestro pipeline todavía necesitamos la VM. Pero podemos mover las builds de CI al agente de Azure.

También puedes leer mi guía sobre MSDyn365FO y Azure DevOps ALM.

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 deberías ver un nuevo proyecto en LCS llamado PEAP Assets, y dentro de la Asset Library en la sección Nuget package encontraréis los nugets.

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
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:

También puedes leer la guía completa sobre MSDyn365FO y Azure DevOps ALM.

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.

Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

Después de la actualización dl último post sobre llamar a la API de LCS desde Azure DevOps me di cuenta que crear una pipeline con una contraseña a la vista no era muy seguro. ¿Cómo podemos añadir un extra de seguridad a pipelines? Una vez más podemos acudir a una herramienta de Azure para ayudarnos, Azure Key Vault.

Azure Key Vault

Key Vault es un servicio que nos permite guardar certificados o secretos de forma segura y usarlos en nuestras apps o servicios. Y como muchos otros servicios de Azure tiene un coste pero es muy bajo y, para un uso normal, la factura será de 1 céntimo o ninguno al mes. ¡No seáis rancios con la seguridad!

Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

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.

Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

Ya he escrito unos cuantos posts sobre la ALM (Application Lifecycle Management) de desarrollo  para Dynamics 365 for Finance and Operations in the past:

La posibilidad de hacer CI/CD real es una de mis cosas favoritas de MSDyn365FO, pasar del «¿Qué control de código?» a «O usas control de código o muere» ha sido una maravilla. Nunca me cansaré de decirlo.

Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

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.

Aquí puedes leer mi guía completa sobre Dynamics 365 for Finance and Operations y Azure DevOps.

En la primera parte de este post vimos a importancia de Azure DevOps y como configurarlo para MSDyn365FO.

Quiero empezar esta segunda parte con una pequeña pataleta. Como decía en la primera parte, los que llevamos años trabajando con AX nos habíamos acostumbrado a no usar un control de versiones. MSDyn365FO nos ha llevado a un terreno sin explorar, con lo que no es raro que cada equipo haya decidido trabajar de una forma u otra según las experiencias que se hayan ido encontrando. Evidentemente, hay un componente del interés de los miembros de estos equipos para investigar un poco por su cuenta sobre la gestión de código, ramas y metodologías. Muchas veces a base de experimentación y prueba-error, y con las prisas de algunos proyectos esto sale mal, o muy mal. Y aquí he echado de menos un poco de guidance por parte de Microsoft (que igual la hay y me lo he perdido).

A pesar de esta quejita el camino y el aprendizaje ha sido, y creo que lo que viene también será, bastante divertido 😉

Estrategias de branching

Vaya por delante que no soy, ni mucho menos, un experto en gestión del código ni Azure DevOps. Todo lo que viene a continuación es fruto, como comentaba antes, de la experiencia (y las meteduras de pata) de casi 3 años trabajando con MSDyn365Ops. En este artículo de la documentación sobre estrategias de branching hay más información sobre branching y links a artículos del equipo de DevOps. Y en la Biblioteca de herramientas y guías de los DevOps Rangers hay incluso muchísimo más!

La verdad es que me encantaría una sesión de FastTrack sobre esto y, creo que no la hay. EDIT: parece que no lo vi y sí que existe una sesión de FastTrack sobre esto que se llama Developer ALM. Gracias a Dag Calafell (twitter) por la información!

Como vimos en la primera parte cuando desplegamos la máquina de Build se crea la carpeta de Main. Lo normal es que en un proyecto de implantación se desarrolle sobre Main hasta el momento del arranque, y que justo antes del go live se cree una branch (rama) de desarrollo. El árbol de código quedaría así:

Ramas despues de branch

En ese momento los mapeos de las máquinas de desarrollo deben cambiarse para que apunten a esta nueva rama de dev. Esto permitirá seguir desarrollando mejoras o corrigiendo errores y decidir el momento en el que se van a mover a producción haciendo un merge a Main.

Esta estrategia es bastante sencilla y que no provoca muchos quebraderos de cabeza. En mi anterior trabajo en cliente final decidimos usar 3 ramas por peculiaridades de la empresa. Main, Dev y Test con merges de Dev a Test y de Test a Main. Un dolor de cabeza al final, gestionar las 3 ramas, con upgrades de versiones, decenas de changesets pendientes y un partner ISV que no ayudaba mucho era bastante divertido.  ¿Pero, y lo que aprendí? Buf.

En cualquier caso un consejo: intentad evitar que se queden changesets pendientes de mergear durante mucho tiempo. La cantidad de conflictos que aparecen y hay que resolver a mano es directamente proporcional a lo viejo que sea el changeset.

Llegado a este punto no puedo hacer suficiente hincapié en lo de normal de más arriba. Como digo, esto lo escribo basado en mis experiencias. Está claro que no es lo mismo trabajar en un partner de implantación que en un ISV. Un ISV tiene la necesidad de mantener diferentes versiones de su producto y no va a usar una rama Main y otra Dev sinó que puede tener una (o varias) por versión a mantener para dar soporte a todos los clientes (aunque desde la 8.1 y el fin del overlayering ya no es necesario). Para más «ideas» el artículo que he enlazado al principio es perfecto para empezar.

Builds

En la primera parte y en otro post (Builds que no responden en Azure DevOps) expliqué un poco acerca de las builds. Ya vimos que la definición de build que se genera por defecto al desplegar el servidor es como la de la imagen inferior:

Pasos de la definición de build por defecto

Esta build tiene todos los pasos con los que se ha creado activos. Podemos desactivar (o borrar) los pasos que no necesitemos. Por ejemplo, los 3 de testeo si no tenemos tests creados, o la sincronización y despliegue de informes.

Podemos crear nuevas definiciones de build a partir de esta o de 0 (pero es más sencillo y rápido duplicar esta y modificarla) para que se apliquen a otras ramas u otros motivos.

Con la versión 8.1 de MSDyn365FO han desaparecido los hotfixes de código X++, todos son binarios. Esto lo que implica es que en la carpeta Metadata de nuestras ramas ya no van a aparecer los modelos del estándar, solo los nuestros. Hasta la versión 8.0 era muy útil tener una definición de build únicamente para nuestros modelos y otra con todos los modelos. Con esto lo que se consigue es tener un DP en mucho menos tiempo que generándolo para todos los modelos. Si se aplica algún hotfix hay que generar el DP de la rama con todos los modelos, pero si sólo hay código propio no hace falta generar un paquete con todos los modelos.

Y hasta aquí la información desactualizada. A estas alturas todos los proyectos deberían estar en 8.1 o listos para estarlo, que en abril llega One Version!

Otra opción que es bastante útil es que, por ejemplo, podemos crear una nueva definición que lo único que haga es compilar una rama:

Definicion build continua

Esta build no hace nada más, solo compila. Así a priori no parece muy útil pero si activamos la opción de integración continua:

DevOps continuous integration

Después de cada check-in de cada desarrollador se lanzará una build que compilará todo el código y fallará si hay algún error. ¿Claro que no debería fallar no? Porque todos compilamos los proyectos antes de hacer el check-in, ¿verdad?

tysonjaja

Pues por eso y porque las prisas son malas y a veces tenemos que vivir con ellas, esta build puede ser bastante útil. Sobretodo cuando lo tengamos configurado para la rama Main y nos «chive» los errores que pueden aparecer después de un merge con conflictos. Y cuando hay que pasar algo urgente a producción y tenemos poco margen nos interesa poder generar el paquete lo antes posible. Usando esta estrategia conseguimos que generar un DP con nuestros paquetes tardara 9 minutos en vez de 1h15m generando todo.

Igual alguien con más conocimiento de esto piensa, pero eso no lo puedes hacer con…

Gated check-ins

Con este tipo de check-in el código se compila ANTES de que el check-in se haga efectivo. Si falla la build el changeset no se hace efectivo hasta que se corrijan los errores y se vuelva a hacer el check-in.

A priori esta opción parece ideal para los check-in de merges de una rama de desarrollo a Main. Los problemas que me he encontrado con esta opción son varios:

  • Si haces múltiples merge y check-ins de un mismo desarrollo y el primero falla no se mergea, pero si el segundo compila correctamente sí.
  • Problemas con las notificaciones de errores y código pendiente al fallar el check-in
  • En merges con más de un check-in se encolan muchas builds (y por defecto solo tenemos un build agent disponible…)

Seguro que esto tiene solución, pero no he sabido encontrarla. Y de todas formas la opción de integración contínua que comentaba antes nos ha funcionado perfectamente para validar que la rama compila sin errores. Como digo todo esto ha sido fruto de la investigación del equipo y prueba-error.

Conclusiones

Supongo que la mayor conclusión es que con MSDyn365FO hay que usar Azure DevOps. Es obligatorio, no hay otra opción. Los que no lo estéis haciendo, si es que alguien no lo hace, hacedlo. Ya. Revisad vuestra forma de trabajo y olvidemos de una vez por todas AX, MSDyn365FO a nivel técnico es otro producto.

La verdad es que, a los desarrolladores, MSDyn365FO nos ha acercado un poco más a lo que es un proyecto de desarrollo de software clásico como puede ser uno de .NET o Java. Pero no del todo. Un proyecto de ERP tiene muchas peculiaridades, y creo que no partir de zero en el desarrollo del producto, tener una base que nos «obliga» un poco a seguir una línea, nos limita en algunos aspectos y en el uso de ciertas técnicas y metodologías.

Y hasta aquí estos dos posts sobre Azure DevOps. Espero que le sean de ayuda a alguien. Y si alguien con más experiencia, o mejores ideas, quiere recomendar algo, ¡los comentarios están abiertos!

¡NO sigas este enlace o serás bloqueado en este sitio!