La llegada de los entornos unificados de desarrollo cambia algo más que el lugar donde se administra Dynamics 365 Finance and Operations. Al trabajar con herramientas locales, el desarrollador puede conservar metadatos de diferentes versiones y convertirlos en una base práctica para analizar los cambios que introduce Microsoft.
El caso fue documentado por Cruz Margaix Huerta en su artículo “Auditar cambios entre versiones de Dynamics 365 F&O con GitHub Copilot”. Su experiencia muestra cómo un inconveniente de almacenamiento puede transformarse en una herramienta de análisis técnico.
Esta entrada complementa nuestra guía sobre UDE, USE y UPE en D365FO, donde revisamos el propósito y las restricciones de cada tipo de ambiente unificado.
Por qué el desarrollo local cambia la comparación de versiones
En un Unified Developer Environment (UDE), las herramientas y los metadatos de Finance and Operations se utilizan desde el equipo del desarrollador. Cuando se trabaja con diferentes versiones o builds, pueden coexistir localmente conjuntos completos de archivos estándar.
La autora señala que estos objetos se almacenan bajo los datos locales de la aplicación de Windows, en una estructura asociada a %LOCALAPPDATA%\Microsoft\Dynamics365\, con carpetas diferenciadas por versión y build.
En su equipo, cada conjunto superaba el medio millón de archivos y ocupaba aproximadamente 18 GB. Estas cifras deben entenderse como una medición del caso documentado: el tamaño real depende de los componentes, versiones y metadatos instalados.
De almacenamiento acumulado a evidencia técnica
Conservar temporalmente dos versiones permite investigar preguntas que antes exigían mantener máquinas de desarrollo en builds distintos. El valor no está únicamente en disponer de los archivos, sino en organizarlos para que una herramienta de análisis pueda recorrerlos de forma consistente.
GitHub Copilot puede utilizar el contexto de un espacio de trabajo para localizar archivos, relacionar referencias y resumir diferencias. En este escenario puede ayudar a:
- Comparar una clase estándar entre dos builds.
- Revisar los cambios de todas las clases de un modelo.
- Identificar objetos nuevos, modificados o eliminados.
- Detectar nuevas clases relacionadas con
Flight. - Generar un inventario con paquete, modelo y ruta del objeto.
- Preparar un archivo CSV para revisar y conservar los resultados.
En la prueba publicada, la consulta sobre clases Flight produjo un CSV con 493 resultados. Esa cantidad corresponde a la comparación concreta realizada por la autora y no debe interpretarse como un inventario oficial de Dynamics 365 Finance 10.0.49.
Flujo recomendado para una comparación
- Identificar los builds exactos. Registrar la versión de aplicación y la revisión utilizadas como origen y destino.
- Mantener carpetas separadas. Evitar mezclar archivos pertenecientes a diferentes builds.
- Abrir una carpeta superior como espacio de trabajo. Así, la herramienta puede consultar ambos conjuntos sin trasladarlos a un repositorio público.
- Definir instrucciones del proyecto. Documentar cómo se relacionan los nombres de carpetas con las versiones de Finance and Operations.
- Limitar cada consulta. Comparar primero una clase, un modelo o una familia de objetos claramente definida.
- Solicitar evidencia. Pedir siempre archivo, ruta, paquete, modelo y fragmento donde se detectó el cambio.
- Exportar el inventario. Guardar resultados estructurados para revisión, trazabilidad y pruebas.
- Validar con una comparación determinista. Confirmar los hallazgos mediante Git, herramientas de diferencias o scripts antes de tomar decisiones.
Ejemplos de consultas útiles
Compara esta clase entre los dos builds y enumera los métodos agregados, modificados o eliminados, indicando la ruta de cada archivo.
Analiza las clases del modelo seleccionado y genera un CSV con objeto, paquete, modelo, tipo de cambio y evidencia.
Identifica las clases Flight presentes únicamente en la versión nueva y separa los resultados por modelo.
Cuanto más precisa sea la consulta, más fácil será comprobar el resultado. Pedir un resumen general de cientos de miles de archivos puede provocar omisiones o conclusiones difíciles de auditar.
Qué aporta al proceso Evergreen
Esta técnica puede reforzar el análisis previo a una actualización porque permite buscar cambios relacionados con:
- Extensiones que dependen de métodos estándar.
- Clases o métodos reemplazados.
- Variaciones en firmas y parámetros.
- Nuevas funcionalidades controladas mediante flights.
- Objetos utilizados por integraciones o procesos batch.
- Regresiones que aparecen después de cambiar de build.
No reemplaza las notas de versión, los avisos de deprecación ni las pruebas funcionales. Su valor está en añadir evidencia de código a la evaluación de impacto.
Seguridad, propiedad intelectual y gobierno
Abrir una carpeta local con GitHub Copilot no significa que el código deba publicarse en GitHub. El código estándar de Microsoft no debería cargarse en un repositorio público ni redistribuirse.
También deben revisarse el plan y las políticas de datos de Copilot. GitHub indica que los datos de clientes de Copilot Business y Enterprise están protegidos por su acuerdo de tratamiento y no se utilizan para entrenar modelos sin autorización. Para planes individuales, las interacciones pueden utilizarse para mejorar modelos desde abril de 2026, aunque existe una opción para desactivarlo.
Antes de incorporar el procedimiento a un equipo conviene:
- Utilizar una licencia y una cuenta autorizadas por la organización.
- Revisar las políticas de contenido y exclusiones.
- No incluir código de clientes, credenciales ni configuraciones sensibles.
- No publicar el código estándar ni los metadatos completos.
- Conservar únicamente informes y evidencias necesarias.
- Revisar manualmente todos los resultados generados por IA.
Coste y almacenamiento
El artículo señala un consumo reducido por consulta en sus pruebas. No es apropiado convertir esa observación en un coste fijo: el consumo depende del plan de Copilot, el modelo seleccionado, las solicitudes premium y el volumen de contexto procesado.
El almacenamiento también requiere disciplina. No es necesario conservar indefinidamente todos los builds. Puede definirse una política que mantenga la versión actual, la versión objetivo y la evidencia generada, eliminando las copias obsoletas cuando ya no sean necesarias.
Conclusión
UDE permite convertir los metadatos locales de diferentes builds en una fuente de análisis para las actualizaciones de Dynamics 365 Finance and Operations. GitHub Copilot facilita la exploración en lenguaje natural, pero la utilidad real aparece cuando el proceso conserva versiones exactas, produce resultados estructurados y valida cada hallazgo con herramientas deterministas.
El patrón es especialmente útil para preparar regresiones y evaluar extensiones antes de adoptar una nueva versión. Debe aplicarse con controles de seguridad, propiedad intelectual, almacenamiento y revisión humana.