Pues eso, soy programador con experiencia en Microsoft Dynamics AX, he participado en varios proyectos sobre las versiones 2009, 2012, R2, R3… y finalmente, mi empresa empieza a trabajar en un proyecto de Dynamics 365 for Finance and Operations, y pienso… ¿Y ahora qué?
Lo primero de todo, aclarar que mi intención con este artículo no es la de sentar cátedra, imponer mi punto de vista o rechazar el de otros, al contrario, con este artículo me gustaría estimular la curiosidad de otros compañeros, generar debate y sobretodo poner en duda los mecanismos o las estrategias que estamos utilizando en nuestro día a día con un único fin, el de mejorar como profesionales. Es por ello, que te invito desde ya a poner en duda y a comentar sobre todo lo que leas de aquí en adelante para generar un debate que nos pueda enriquecer a ambos.
Soy muy bueno programando con X++ ¿eso ha cambiado?
Como ya sabréis, #MSDyn365FO es una aplicación web (el AOS ya no es un servicio de Windows, sino, un sitio web que corre en IIS), pero eso no quiere decir que necesitemos conocimientos de programación web para continuar trabajando en este producto. La base general del sistema no ha cambiado, seguimos programando principalmente con X++ y la funcionalidad básica del sistema es la misma.
¿Significa esto que puedo seguir trabajando como lo he hecho hasta ahora? Para nada. El paradigma principal de customización del ERP ha dado un giro de 180º. Hasta ahora, estábamos acostumbrados a introducir nuestro código en cualquier punto del sistema (overlayering), modificando así su comportamiento estándar. Esto se acabó. Actualmente tenemos que trabajar con un modelo de extensiones en el que no todo vale. Debemos pensar muy bien las modificaciones a realizar, valorar su viabilidad, teniendo siempre en cuenta que el principio de todo esto es el de extender la funcionalidad del sistema, no cambiarla. Gracias a esto, el core de la aplicación quedará «intacto» y podremos olvidarnos para siempre de las temidas migraciones para dejarnos llevar por el fantástico One Version: Actualizaciones periódicas que nos permitirán trabajar siempre con la última versión del producto.
No todo en esta vida es X++
Relacionado con el punto anterior: Se acabó la «comodidad». Ya no nos vale escondernos debajo de esa capa protectora que era el X++, con él todo era posible. No necesitábamos nada más que esto para ser felices. Ahora es necesario (por no decir obligatorio) ser curioso. El cambio de IDE a Visual Studio nos permite una integración mucho más rica con Azure DevOps, tenemos LCS para gestionar los entornos y los despliegues, tenemos que ser capaces de ver más allá de X++, conocer Azure, conocer la Power Platform (Power Apps, Power Automate, Power BI), interesarnos por herramientas como RSAT y ATL para la automatización de testing. En definitiva, abrir nuestra mente más allá del ERP para ser capaces de encontrar soluciones más ricas y escalables. Está claro que al principio puede ser un poco duro, pero al final, hace tu trabajo mucho más interesante y divertido.
Gestión de Paquetes y Modelos
Una de las primeras preguntas que me hice cuando comencé a trabajar con #MSDyn365FO fue: ¿Cuantos paquetes y modelos tengo que crear? ¿Como organizo el código desarrollado? Aquí la respuesta que recibí por parte de ingenieros de Microsoft fue la siguiente: Hazlo tan simple como sea posible.
Y así lo intentamos hacer desde el primer día, lo que no quiere decir que lo hiciéramos siempre bien, al contrario, hemos ido aprendiendo de la experiencia y a día de hoy, hemos alcanzado un sistema en el que todos los del equipo nos sentimos cómodos. Solemos hacer un único paquete que contendrá todos los objetos de nuestras personalizaciones, divididos en tantos modelos como módulos «modifiquemos». Es decir, si tenemos que realizar un desarrollo concreto para el módulo de Proyectos, crearemos nuestro modelo AXZProjects dentro de nuestro paquete Axazure, si necesitamos añadir ciertos campos a la CustTable, esta modificación irá directa a AXZCustomers, y aprovechamos el modelo Axazure para almacenar todos aquellos útiles o helpers que podemos usar de manera cross en varios desarrollos (gestión de dimensiones, DLLs externas…). De este modo dejamos todo «nuestro» código fácilmente localizable y lógicamente ordenado, sin añadir mucha complejidad a la hora de hacer referencias entre paquetes.
Esta organización nos es válida cuando trabajamos en un proyecto de implantación. Por otro lado, tenemos los ISV o los productos internos, en los que tenemos un paquete individualizado por cada uno de ellos.
No digo que esta sea la forma correcta de trabajar, sino que, es la forma en la que nosotros, en Axazure, nos sentimos cómodos a día de hoy, y ya te puedo avanzar, que es más que probable que de aquí a un tiempo, esta forma cambie, igual que ha ido cambiando en los últimos años, puesto que lo mas importante de todo esto, como ya he mencionado, es cuestionarte si lo estás haciendo bien, y ver si lo puedes mejorar.
En todo este tiempo he visto distintas formas de organizarse. Un solo modelo, distintos modelos por módulos, hasta un paquete y modelo por cada GAP/Desarrollo. Imaginaos la cantidad de referencias, ficheros de etiquetas, extensiones… que se necesitará crear. De nuevo, no digo que sea una forma errónea de trabajar, sino que personalmente, me parece que aporta mas complejidad que valor. Al final, cuando decido una estrategia concreta, siempre hago el mismo balance: Sencillez o complejidad de mi solución versus valor que me aporta. Si el valor compensa lo complejo de la misma, vamos adelante con ello, pero la premisa siempre es la misma, tan simple como sea posible.
Repositorio de código y Gestión de ramas
En este apartado, igual que en el anterior, mi recomendación es que definas una estrategia de ramas tan sencilla como sea posible, y solo añadas complejidad a la misma cuando el valor que aporte sea superior al coste de gestionar esta complejidad añadida.
Actualmente, y después de hacer varios cambios durante estos últimos 3 años, trabajamos con el siguiente esquema:
- Una rama DEV por cada desarrollador
- Rama MAIN
- Rama RELEASE
Esta estrategia nos permite tener nuestro código «a salvo» siempre. Podemos generar tantos changeset en nuestra rama DEV como sea necesario, lo que nos da, por un lado, tranquilidad, ya que todo nuestro código está en el repositorio, y al hacer tantos check-in como necesitemos, también nos permite cambiar, testear, borrar, re-escribir nuestro código sabiendo que podemos hacer roll-back en cualquier momento. (Es una forma de simular los repositorios locales de GIT, ya que TFVC no tiene esta posibilidad).
Por otro lado, seremos capaces de, una vez nuestro desarrollo esté finalizado, hacer un único merge a la rama MAIN con todas nuestras modificaciones, dejando el listado de changesets de esta rama bastante limpia y controlada.
Como decía, hasta el momento esta solución nos aporta bastante seguridad, manteniendo la complejidad de la gestión de las ramas al mínimo posible.
Dudo mucho que esta sea la mejor estrategia, de hecho, somos bastante novatos en este mundo, por lo que probablemente haya una mejor, pero nos sentimos cómodos con ella y nos aporta bastante valor sin dificultar nuestro día a día.
Entorno build, Pipelines de AZDO e Integración y Despliegue contínuo
En este apartado concreto, me voy a permitir la licencia de ser un poco más crítico y tajante, basándome en la experiencia acumulada en los proyectos, y sobretodo, en las auditorias realizadas.
En primer lugar hablemos de la generación de paquetes para desplegar (deployable packages) en otros entornos.
Todos sabemos que desde nuestro entorno de desarrollo, podemos abrir Visual Studio, ir a Dynamics 365 > Deploy > Create Deployment Package…, podemos seleccionar los Paquetes que queremos desplegar, generar nuestro deployable package y subirlo a LCS para aplicarlo, verdad?
Pues, por favor, ¡NO LO HAGAS MÁS!. De verdad, no es la forma correcta de hacerlo. Aquí no hay opinión, es un hecho. De esta manera estás corriendo el riesgo (innecesario) de desplegar código que no querías o de desplegar versiones antiguas de un objeto, porque, a quién no se le ha olvidado hacer un get latest de vez en cuando? Pues eso, podemos generar un paquete que no contenga esas modificaciones de última hora que hizo nuestro compañero.
Y te preguntarás…, ¿entonces, como generamos el DP? Pues para eso está el entorno Build (por ahora, pero de eso ya hablaremos en otro momento). El flujo que debemos seguir desde que generamos nuestro código hasta que sube a LCS para ser desplegado es el siguiente:
Es decir, todas las máquinas de desarrollo, están continuamente subiendo y bajando código en el repositorio de AZDO (Azure DevOps), y en última instancia, es el entorno Build el encargado de obtener todo el código del repositorio, y generar el DP para poder subirlo a LCS. De este modo, siempre desplegaremos todo y solo el código que esté en el repositorio. Los últimos cambios de nuestro compañero estarán ahí, y nuestro código de prueba o nuestro job para cambiar una cosa que hice mal no.
Nos hemos encontrado con el argumento de: «Es que el coste de mantener un entorno de Build no lo habíamos tenido en cuenta, no podemos permitirnos este aumento de repente». Por eso es importante dejar claro al cliente, desde el principio, que este entorno es necesario, y explicar el por qué, de este modo verán que, de nuevo, lo que nos aporta es muy superior al coste del mismo.
Por lo tanto, ya tenemos claro que lo que debemos hacer a la hora de generar nuestro DP es, entrar en el entorno Build > Get Latest > Compilar y sincronizar > Generar paquete > Subirlo a LCS. Fácil no?
Pues, no no no no no, y ¡¡mil veces no!! El entorno Build (por regla general) es un entorno al que no necesitamos entrar para nada, no necesitamos mapear las carpetas locales con el repositorio de código, no tenemos que generar estos paquetes de forma manual. ¿Por qué?. Pues la respuesta es muy sencilla, porque podemos automatizar todo esto utilizando los pipelines de Azure DevOps.
Cuando desplegamos el entorno de tipo Build desde LCS, se genera de forma automática un nuevo Pipeline dentro de Azure DevOps. Con este pipeline, un poco de ganas e interés, y 30 minutos o 1 hora por cada nuevo proyecto que tengamos, podemos conseguir tener todo el proceso de compilación y de despliegue automatizado al 100%. Bueno, al 90% puesto que la subida a producción todavía se debe programar de forma manual.
Personalmente, creo que el uso de los Pipelines de Azure DevOps en Dynamics 365 for Finance and Operations es una de las cosas que más ha mejorado nuestra vida como programadores/administradores de Dynamics AX/365FO, el valor que aporta es infinito, así como el tiempo que ahorramos en cada uno de nuestros despliegues. Como decía, con un poco de ganas, aprendizaje e imaginación puedes definir una estrategia de Integración y Despliegue Continuo bastante completa que te va a permitir centrarte más en hacer un trabajo de calidad automatizando procesos «repetitivos» como es el de desplegar los desarrollos en distintos entornos, y por supuesto, hacer que estos procesos sean más seguros.
Y ¿cómo hacemos todo eso? Pues ese no es el propósito inicial de este artículo, pero si has llegado hasta aquí, no te has dormido por el camino y estás interesado en mejorar tu vida y la de los que te rodean, te aconsejo visitar el blog de Adrià, concretamente la página en la que ha agrupado todos los artículos que ha escrito sobre #MSDyn365FO y Azure DevOps, ¡Disfrútalo!
Conclusiones
Resumiendo, voy a dejar por escrito estos puntos que considero imprescindibles:
- No tengas miedo al cambio
- Echa un vistazo a lo que tienes alrededor (Azure, Power platform, DevOps…)
- Haz caso a los expertos (por supuesto hablo de Microsoft, no de mi :))
- Planifica correctamente el proyecto desde el inicio (entornos necesarios)
- Disfruta aprendiendo y mejorando
Para terminar, me encantaría leer tu opinión sobre los puntos que hemos tratado en este artículo y poder aprender de tu experiencia. Seguro que tienes mejores estrategias de definición de modelos, gestión de ramas…, o algún consejo que darme sobre Dynamics o DevOps en general. ¿Me los cuentas?
2 comments / Add your comment below