Aunque todo proyecto de Dynamics 365 es un mundo, los desarrollos suelen ser los mismos. En este post explicaré algunos tips de cómo organizarlos enfocado especialmente a las opciones de Azure DevOps.
Disclaimer: esta organización no está orientada a DevOps. Eso lo trataremos más adelante.
Primero: piensa en repositorios
¿Todo en un único repositorio o en varios? Hace años era común organizar todo el código en un mismo repositorio. Dentro del mismo, ya se empleaban proyectos para distinguir plugins de workflows o webresources. Este planteamiento venía derivado de la capacidades de los conroles de código fuente. Era fácil verse con limitaciones por el servidor de turno.
Actualmente gracias a Azure DevOps y sus capacidades, tenemos a disposición la creación de tantos repositorios como se necesiten. Lo importante es el criterio para determinar la creación de cada uno. Es así cómo podemos organizar de forma general los siguientes repositorios de un proyecto Dynamics:
- Workflow Activities
- Plugins
- Webresources
- Azure Functions / Webhooks
- Otros
Es una orientación inicial. Evidentemente, dependiendo del proyecto, podrán ampliarse más o menos. Pero la idea principal es aislar los elementos genéricos de Dynamics.
Segundo: complejidad
Una vez con un lugar para cada desarrollo según su naturaleza, cabe preguntarse cómo estructurar cada uno. ¿Un proyecto con muchas clases de plugins o uno por cada uno? ¿Es necesario un proyecto para los webresources? ¿Cómo organizarmos las carpetas?
Dependiendo de la complejidad de nuestro proyecto, esta decisión puede ser importante. A grandes rasgos, distingo las siguientes variables:
- Si el proyecto no requiere mucho código plugins/worklows, un proyecto para plugins y workflows serviría.
- Si el proyecto tiene algo más de complejidad:
- Para plugins, crear proyectos por cada entidad. Así cada uno tratará las funciones que apliquen a cada entidad. Permite que un desarrollor se centre en una sóla entidad sin impedir que otros trabajen en las demás.
- Para workflows, organizar los ensamblados de forma lógica. Una aproximación interesante es dividirlos en:
- Comprobaciones. Un ensamblado que sólo tiene funciones de comprobación. Son preguntas en base a parámetros que devuelven true/false.
- Obtenciones. Ensamblado encargado de devolver datos del CRM según sus paramétros. Nunca actualiza información, sólo consulta.
- Actualizaciones. Lo contrario al anterior, manipula información en la BBDD.
- Útiles. Ensamblado para utilidades comunes y particulares para nuestro proyecto que puedan ser compartidas por distintos workflows. Un mini workflow tools a medida.
- Si la complejidad es enorme, entender que tanto los plugins como workflows deban tener su propio proyecto por funcionalidad. Es un escenario que requiere muchísima más capacidad de organización pero permite evadir problemas de coordinación entre los miembros del equipo al desarrollar.
- Sobre los webresources, generalmente baste una organización en torno a un proyecto dummy donde organizar los archivos en CSS, JavaScript y HTML.
Tercero: ramas
Si todavía no implementas DevOps en Dynamcs 365, no desesperes, quedan opciones. Debido a las características de trabajar con soluciones, es normal encontrar dificultades para adaptar nuestra metodología a DevOps. Además de los pequeños detalles que generan debate.
El siguiente paso en una organización sencilla, sería identificar las ramas posibles con las que vayamos a trabajar. Aunque para los desarrollos de Dynamics trabajaremos siempre con soluciones, no está mal tener las capacidades de las ramas para tener mejor organizado nuestros desarrollos.
Si tu proyecto es clásico con una metodología basada en desarrollo, UAT y producción, la siguiente oragnización sería suficiente por repositorio:
- master. Donde estarán los pull request de los desarrollos que hayan sido validados en UAT. Es la rama por defecto por lo que al crear el repositorio lo primero que habrá que hacer son las otras dos ramas.
- uat. Específica para los desarrollos testeados con éxitos y que se llevarán en la solución a UAT desde desarrollo.
- dev. Rama base donde se trabajará. Dependiendo del equipo y la organización del mismo podrá a su vez subdividirse en ramas para abarcar el trabajo (por desarrollo, funcion, sprint, etc.).
Cuarto: otros elementos
En la actualidad es casi imposible ver proyectos donde no existan terceros elementos que desarrollar y que no estén en la nube. Los desarrollos serverless están a la orden del día y por ello merecen nuestra atención.
En esta breve recomendación, sólo resaltaré la importancia de conocer antes el tipo de producto para realizar la funcionalidad deseada. Una vez elegido, establecer si es necesario aislar por su complejidad funcionalidad en varios repositorios o en uno, o si necesita dependencias de ensamblados a medida.
En la práctica, es práctico organizar un repositorio para todas las Azure Functions o Webhooks donde puedan compartir proyectos de funcionalidades comunes; para recursos que necesiten más aislamiento como algún App Service específico, es mejor dejarle su propio espacio; y para los demás… ¡hay tantas opciones!
En todo caso, siempre bien tener un repositorio cajón desastre sobre todo a inicio de proyecto para pequeñas POCs u otro tipo de necesidades. Si bien la clave es anticipar a alto nivel los productos necesarios organizados por código.
Aunque como todo evoluciona, ¡lo mejor es estar atento a los cambios!
Power Platform, Dynamics 365 & Beyond! 