TFVC no va a desaparecer mañana. Pero si hoy estamos diseñando una nueva estrategia de desarrollo para Dynamics 365 Finance & Operations, seguir aumentando la dependencia de TFVC cuesta justificarlo.
Durante años, TFVC encajó muy bien con el mundo D365FO: Visual Studio, PackagesLocalDirectory, Build VM, branches por versión y despliegues gobernados desde LCS. Muchos productos maduros siguen trabajando así y, si el proceso es estable, no hay ningún premio por romperlo de un día para otro.
El problema es otro: Microsoft ya dejó bastante clara la dirección. Git es el proveedor de control de versiones predeterminado para nuevos proyectos de Azure DevOps, TFVC se considera feature complete y la inversión futura está concentrada en Git. Además, Microsoft ya recomienda comenzar a mover los proyectos TFVC existentes hacia Git.
En D365FO esto dejó de ser una discusión teórica. Microsoft tiene documentación específica para X++ en Git y sus guías actuales para los entornos unificados parten de un repositorio Git con código X++ y proyectos de Visual Studio.
Entonces, ¿hay que abandonar TFVC ahora?
No. Y probablemente ese sea el error más fácil de cometer.
Una plataforma estable en TFVC, con productos en producción, branches mantenidos, pipelines probados y dependencias todavía ligadas a LCS, no necesita una migración traumática solo para poder decir que usa Git.
La recomendación práctica es bastante menos dramática: dejar de construir futuro sobre TFVC mientras mantenemos estable lo que todavía lo necesita.
TFVC puede seguir siendo parte del presente. Lo que ya no parece razonable es convertirlo en la base de los próximos cinco años de ALM.
¿Qué cambia realmente con Git para un equipo D365FO?
La diferencia no está en poder guardar un archivo X++. Ambos sistemas pueden hacerlo. El cambio importante está en cómo organizamos el ciclo completo de desarrollo.
Con Git podemos trabajar con branches ligeros para una funcionalidad, un hotfix o una versión específica; integrar mediante Pull Request; ejecutar validaciones antes del merge; y mantener el pipeline como código mediante YAML.
En un producto D365FO esto permite que un Pull Request deje de ser simplemente una revisión visual y se convierta en una verdadera puerta de calidad:
Feature branch
↓
Pull Request
↓
Compile X++
↓
Best Practices / CAR
↓
Validaciones ISV
↓
Tests
↓
Merge a main
↓
Build
↓
Unified Package
↓
PPAC
Ese cambio es mucho más interesante que sustituir un botón de Check-in por uno de Commit.
Dos detalles que hoy pesan bastante
El primero es el Build moderno de D365FO. La documentación actual de Microsoft para entornos unificados utiliza repositorios Git, paquetes de referencia NuGet, Azure Pipelines y genera un Power Platform Unified Package. Ese paquete puede incluir el resultado compilado de X++ y, opcionalmente, soluciones de Dataverse.
El segundo es el despliegue. Microsoft ya documenta pipelines que promueven el Unified Package entre Test, Preproducción y Producción, utilizando Azure DevOps Environments, aprobaciones y Power Platform Build Tools. Es decir, Git no está llegando solo: forma parte de una evolución más amplia de ALM alrededor de PPAC y Power Platform.
¿Y PackagesLocalDirectory?
Aquí conviene no vender humo. TFVC tiene años de integración histórica con el modelo tradicional de desarrollo D365FO y PackagesLocalDirectory. Git requiere configuración adicional y Microsoft documenta consideraciones específicas para trabajar con X++.
Eso significa que la transición debe probarse con un escenario real: metadata, modelos, referencias, compilación, ISV, generación del paquete y despliegue. Que un desarrollador pueda hacer git commit no significa que la estrategia ALM esté resuelta.
La estrategia que aplicaría hoy
Corto plazo: mantener en TFVC los productos estables que todavía dependen de ese modelo, pero evitar crear nuevas dependencias. En paralelo, ejecutar un piloto Git completo con un producto o modelo controlado.
Siguiente paso: llevar el piloto hasta el final. No basta con source control. Debe demostrar Git → Build X++ → Best Practices/CAR → Package → PPAC.
Mediano plazo: incorporar Pull Requests, políticas de branch y Quality Gates. Aquí tiene sentido ejecutar el CAR de Microsoft y las reglas propias del producto antes de permitir el merge.
Objetivo: que el ALM termine alineado con Git + Azure Pipelines + NuGet + Unified Package + PPAC, manteniendo TFVC únicamente mientras exista una razón técnica concreta para hacerlo.
¿Big Bang? No, gracias
Una migración de control de versiones no debería convertirse en un proyecto de arqueología para trasladar veinte años de historia solo porque podemos hacerlo.
Azure DevOps permite coexistencia y Microsoft mantiene compatibilidad con TFVC. Eso nos da algo valioso: tiempo para hacer una transición controlada.
La pregunta, entonces, no debería ser “¿cuándo apagamos TFVC?”.
La pregunta útil es otra:
“¿Qué dependencia nueva estoy creando hoy que me obligará a seguir usando TFVC dentro de tres años?”
Si la respuesta es “ninguna”, probablemente vamos en la dirección correcta.
Referencias oficiales
- Microsoft Learn — X++ in Git
- Microsoft Learn — Git y TFVC en Azure Repos
- Microsoft Learn — Retirada gradual de TFVC en nuevos proyectos
- Microsoft Learn — Build pipeline de Finance & Operations para entornos unificados
- Microsoft Learn — CI/CD para Finance & Operations Unified Experience
- Microsoft Learn — Release pipeline para Finance & Operations